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This  thesis  applies  a  systems  thinking  methodology  to  produce  a  proof  of 
principle  decision  support  dashboard  that  integrates  relevant  Marine  air-ground  task 
force  (MAGTF)  logistics  systems  to  assist  the  tactical  level  commander  to  better 
manage  ground  and  air  transportation  assets.  For  this  thesis,  the  researchers  define  the 
MAGTF  system  in  terms  of  three  components:  1)  organization  design,  2)  IT  systems,  and 
3)  feedback  control.  The  researchers  looked  at  the  existing  Log  IT  systems  supporting  the 
current  MAGTF  organization  and  assessed  how  well  our  application  design  can  use  and 
access  existing  logistics  databases  to  improve  logistics  decision-making.  The  researchers 
discovered  that  effective  application  design  depends  on  selecting  the  appropriate 
organizational  level  of  war  the  application  is  designed  to  support:  1)  strategic,  2) 
operational  and  3)  tactical.  By  developing  a  proof  of  principle  application  that  accesses 
existing  databases  and  applying  a  systems  thinking  methodology,  the  researchers 
demonstrate  how  information  can  be  used  to  enhance  the  MAGTF  commander’s  decision 
making  for  more  efficient  and  effective  employment  of  transportation  assets  in  the 
battlespace.  The  potential  benefit  of  this  research  is  a  proposed  systemic  structure  with  an 
associated  web  application  that  provides  the  MAGTF  commander  with  critical 
information  for  supporting  operations. 


v 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


vi 


TABLE  OF  CONTENTS 


I.  INTRODUCTION . 1 

A.  EXPEDITIONARY  FORCE  21 . 1 

B.  LOGISTICS  INFORMATION  TECHNOLOGY  AS  A 

CAPABILITY . 2 

C.  BACKGROUND  ON  SYSTEMS  THINKING . 3 

D.  IMPLEMENTING  LOGISTICS  MODERNIZATION . 3 

E.  PROBLEM  STATEMENT . 4 

F.  PURPOSE  STATEMENT . 5 

G.  SCOPE  AND  METHODOLOGY . 5 

1.  Scope . 5 

2.  Methodology . 6 

3.  Primary  Research  Questions . 6 

4.  Benefits  of  Study . 6 

5.  Organization  of  Thesis . 7 

II.  LITERATURE  REVIEW  AND  OVERVIEW  OF  CURRENT  SYSTEM . 9 

A.  LOGISTICS  MODERNIZATION  POLICY . 9 

1.  MARADMIN  444/05 . 9 

2.  MCBUL  4081:  MAGTF  Logistics  Support  Systems 

(MLS2) . 10 

3.  MCO  4000.51:  Automatic  Identification  Technology 

(AIT) . 12 

4.  MCO  4470.1A:  USMC  MAGTF  Deployment  and 

Distribution  Policy  (MDDP) . 13 

5.  Theater  Battle  Management  Core  System  (TBMCS) . 13 

6.  Logistics  Information  Technology  (Log  IT)  Portfolio 

Strategy . 14 

B.  CHALLENGES  OF  IMPLEMENTATION . 15 

1.  Lack  of  Standard  Procedures . 15 

2.  Lack  of  Formal  Reports . 15 

3.  Lack  of  Integration . 16 

C.  GAP  ANALYSIS  AND  WAY  FORWARD . 17 

1.  Gap  Analysis . 17 

2.  The  Way  Forward . 17 

III.  APPLIED  SYSTEMIC  APPROACH  TO  THE  MAGTF . 19 

A.  ORGANIZATION  DESIGN . 19 

vii 


1.  Organization  Design  Related  to  Efficiency . 20 

2.  Strategic  Level . 21 

3.  Operational  Level . 21 

4.  Tactical  Level . 22 

B.  APPLYING  ORGANIZATIONAL  DESIGN  TO  LEVELS  OF 

WAR . 22 

1.  Mechanistic  Design . 22 

2.  Organic  Design . 24 

C.  IT  SYSTEMS  APPLIED  TO  ORGANIZATIONAL  DESIGN . 26 

D.  IT  SYSTEMS  FOR  TRANSPORTATION . 27 

1.  GCSS-MC . 28 

2.  MLS2  Systems . 28 

3.  TBMCS . 29 

4.  Importance  of  Metrics . 30 

E.  FEEDBACK  CONTROL  MODEL . 30 

F.  PROPOSED  SYSTEMIC  STRUCTURE . 32 

IV.  DEVELOPMENT  TOOLS  AND  APPLICATION  METHODOLOGY . 35 

A.  ORACLE  BACKGROUND . 35 

B.  ORACLE  FUSION . 36 

1.  Oracle  F  usion  Applications . 37 

2.  Oracle  Fusion  Middleware . 37 

3.  Oracle  Fusion  Architecture . 38 

C.  SQL  DEVELOPER . 38 

D.  JDEVELOPER . 39 

E.  ADF . 40 

1.  The  Business  Layer . 42 

2.  The  Model  Layer . 43 

3.  The  Controller  Layer . 44 

4.  The  View  Layer . 44 

F.  WEBLOGIC  SERVER . 45 

G.  SUMMARY . 47 

V.  USE  CASE  AND  APPLICATION  OUTLINE . 49 

A.  INTRODUCTION . 49 

B.  USE  CASE . 50 

C.  APPLICATION  DEVELOPMENT  PROCESS . 51 

1.  Products  Utilized . 51 

2.  Database  Extraction/Insertion . 51 

3.  Reviewing  Schemas  and  Data . 52 

viii 


4.  Designing  the  Application . 53 

D.  PAGE  DESIGNS/FUNCTIONALITIES . 54 

1.  Home  Page . 54 

2.  Air  Page . 54 

3.  Ground  Page . 56 

4.  Combo  Page . 58 

E.  FUTURE  ITERATIONS . 60 

VI.  CONCLUSION . 63 

A.  SUMMARY . 63 

B.  RESEARCH  QUESTIONS . 65 

C.  LESSONS  LEARNED  AND  RECOMMENDATIONS . 66 

D.  FUTURE  AREAS  OF  RESEARCH . 69 

APPENDIX  A.  DEPLOYED  MDDOC  STRUCTURE  TEMPLATE . 71 

APPENDIX  B . 73 

A.  TCPT  DATABASE . 73 

1.  TCPT  Schema . 73 

B.  TBMCS  DATABASE . 75 

1.  ATOPLN  Schema . 75 

2.  FROBDB  Schema . 76 

3.  TMBSUP  Schema . 77 

APPENDIX  C . 79 

A.  AIR  PAGE . 79 

1.  View  Objects: . 79 

2.  View  Links . 83 

3.  Application  Module . 84 

B.  GROUND  PAGE . 84 

1.  View  Objects . 84 

2.  View  Links . 89 

3.  Application  Module . 89 

C.  COMBO  PAGE . 90 

1.  View  Objects . 90 

2.  View  Links . 94 

3.  Application  Module . 95 

APPENDIX  D . 97 

A.  GENERAL  STEPS . 97 


IX 


1.  Create  A  New  Application  in  JDeveloper . 97 

2.  Create  a  Connection  in  JDeveloper  to  the  Database  with 

the  Tables  Listed  in  Appendix  B . 97 

B.  BUILDING  THE  MODEL  PROJECT . 98 

1.  Create  Entity  Objects  for  Tables  Listed  in  Appendix  B . 98 

2.  Create  View  Objects  as  Identified  in  Appendix  C . 99 

3.  Create  View  Links  between  the  View  Objects . 100 

4.  Create  All  Required  Transient  Attributes  in  the  View 

Objects . 101 

5.  Create  an  Application  Module  for  Each  of  the  Different 
Pages  (Air,  Ground,  and  Combo)  in  Order  to  Test  the 

View  Objects’  Functionality . 102 

C.  BUILDING  THE  VIEW  CONTROLLER  PROJECT . 102 

1.  Task  Flow . 102 

2.  Home  Page . 104 

3.  Air  Page . 106 

D.  GROUND  PAGE . 112 

E.  COMBO  PAGE . 118 

F.  COMBO  TOTALS . 123 

G.  DEPLOYING  TO  WEBLOGIC  SERVER  FOR  TESTING . 128 

LIST  OF  REFERENCES . 129 

INITIAL  DISTRIBUTION  LIST . 133 


x 


LIST  OF  FIGURES 


Figure  1.  USMC  Logistics  Systems  Architecture.  Source:  R.  Barber,  personal 

communication,  June  30,  2014 . 11 

Figure  2.  Organic  and  Mechanistic  Design.  Source:  Daft  (2013),  p.  31 . 19 

Figure  3.  The  Relationship  of  Organization  Design  to  Efficiency  versus 

Learning  Outcomes.  Source:  Daft  (2013),  p.  98 . 20 

Figure  4.  A  Simplified  Feedback  Control  Model.  Source:  Daft  (2013),  p.  314 . 30 

Figure  5.  Proposed  Systemic  Structure.  Source:  Capt  Sarah  Bergstrom,  2015 . 32 

Figure  6.  Overview  of  the  Fusion  Middleware  Solution.  Source:  Oracle 

(2010) . 38 

Figure  7.  SQL  Developer  Main  Window.  Source:  Oracle  (2013) . 39 

Ligure  8.  JDeveloper’s  Integrated  Development  Environment.  Adapted  from: 

Ronald  (2011) . 40 

Ligure  9.  ADL  Lramework  Architecture.  Source:  Gordon  et  al  (201 1) . 41 

Ligure  10.  ADL  Business  Components.  Source:  Gordon  et  al  (2011) . 43 

Ligure  11.  Task  Llow.  Source:  Gordon  et  al  (201 1) . 44 

Ligure  12.  Oracle  ADL  Architecture.  Source:  Ronald  (2011) . 45 

Ligure  13.  WebLogic  Server.  Source:  Oracle  (2016a) . 46 

Ligure  14.  MEB  Scenario.  Adapted  from:  Marine  Corps  Sponsors  and  Capt 

Snyder  (2016) . 50 

Ligure  15.  ER  Diagram  for  TCPT . 52 

Ligure  16.  ER  Diagram  for  TBMCS . 52 

Ligure  17.  Transportation  Capacity  Tool  Application  Task  Llow . 53 

Ligure  18.  Transportation  Capacity  Tool  Application  Home  Page . 54 

Ligure  19.  Transportation  Capacity  Tool  Application  Air  Page . 55 

Ligure  20.  Transportation  Capacity  Tool  Application  Ground  Page . 56 


Figure  21.  Transportation  Capacity  Tool  Application  Ground  Page . 58 

Figure  22.  Transportation  Capacity  Tool  Application  Combo  Page . 59 

Figure  23.  Transportation  Capacity  Tool  Application  Combo  Totals  Page . 60 


xii 


LIST  OF  ACRONYMS  AND  ABBREVIATIONS 


2D 

two-dimensional 

AAR 

after  action  report 

ABP 

air  battle  plan 

ACE 

air  combat  element 

ADF 

application  development  framework 

AIS 

automatic  information  systems 

AIT 

automatic  identification  technology 

ALU 

Army  Logistics  University 

API 

application  program  interface 

ASR 

assault  support  request 

ATO 

air  tasking  order 

BCS3 

Battle  Command  Sustainment  Support  System 

C2 

command  and  control 

CE 

command  element 

CLB 

combat  logistics  battalion 

CLC2S 

Common  Logistics  Command  and  Control  System 

CMB 

contact  memory  buttons 

DC,  I&L 

Deputy  Commandant,  Installations  and  Logistics 

DLC 

distribution  liaison  cell 

DS 

direct  support 

EF21 

Expeditionary  Force  21 

ELS  2 

enterprise  logistics  support  systems 

ER 

entity  relationship 

GCE 

ground  combat  element 

GCSS-MC 

Global  Combat  Support  System-Marine  Corps 

HQMC,  I&L 

Headquarters  Marine  Corps,  Installations  and  Logistics 

ICC 

integrated  circuit  chips 

IDE 

integrated  development  environment 

ISO 

International  Organization  for  Standardization 

IT 

information  technology 

xiii 


ITV 

in-transit  visibility 

Java  EE 

Java  platform,  enterprise  edition 

LZ 

landing  zone 

LCE 

logistics  command  element 

Lt  Gen 

Lieutenant  General 

Log  IT 

logistics  information  technology 

Log  OA 

logistics  operational  architecture 

LOGMOD 

logistics  modernization 

MAGTF 

Marine  air-ground  task  force 

MARADMIN 

Marine  administrative  message 

MAW 

Marine  air  wing 

MCB 

Marine  Corps  base 

MCBUL 

Marine  Corps  bulletin 

MCCSSS 

Marine  Corps  Combat  Service  Support  School 

MCDP 

Marine  Corps  doctrinal  publication 

MCO 

Marine  Corps  order 

MDDOC 

MAGTF  deployment  and  distribution  operations  center 

MDDP 

MAGTF  deployment  and  distribution  policy 

MEB 

Marine  expeditionary  brigade 

MEF 

Marine  expeditionary  force 

MEU 

Marine  expeditionary  unit 

MLS2 

MAGTF  logistics  support  systems 

MOS 

military  occupational  specialty 

MSC 

major  subordinate  command 

OIF 

Operation  IRAQI  FREEDOM 

OMC 

optical  memory  cards 

OAG 

operational  advisory  group 

PoP 

proof  of  principle 

PRB 

purchase  request  builder 

QUADCON 

quadruple  container 

R2P2 

rapid  response  planning  process 

RAD 

rapid  application  development 

XIV 


RCT 

regimental  combat  team 

RDBMS 

relational  database  management  system 

RFID 

radio  frequency  identification 

SIXCON 

six  container 

SOA 

service-oriented  architecture 

SOP 

standard  operating  procedures 

SQL 

structured  query  language 

TACC 

tactical  air  command  center 

TBMCS 

Theater  Battle  Management  Core  System 

TCPT 

Transportation  Capacity  Planning  Tool 

USMC 

United  States  Marine  Corps 

WgPM 

wing  procedure  manual 

XV 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


xvi 


ACKNOWLEDGMENTS 


We  are  deeply  appreciative  of  the  support  and  guidance  we  have  received  from 
the  various  stakeholders  and  sponsors  through  the  development  of  this  thesis. 
Specifically,  we  want  to  thank  I  MEF  staff  for  hosting  a  site  visit  and  providing  us  with 
valuable  feedback.  We  also  want  to  recognize  Lt  Col  Reber,  Major  Harris,  Major  Murphy 
and  MGySgt  Harwood  for  their  valued  contributions  and  continued  support  in  assisting 
our  continuous  requests  for  information.  To  Gregory  Belli,  thank  you  for  all  the  technical 
support  you  provided;  without  it,  we  would  still  be  stuck  inserting  SQL  scripts.  We 
would  also  like  to  thank  our  advisors.  Dr.  Magdi  Kamel  and  Tony  Kendall,  for  their 
wisdom,  guidance  and  stories.  To  our  second  reader,  Sharon  Runde,  we  could  not  have 
finished  this  thesis  without  your  prodigious  amount  of  editing  and  quick  turnaround  time. 
We  want  to  thank  our  dogs,  Rocky  and  Charlie,  who  have  been  patient,  loving,  and 
supportive  through  long  hours  of  researching,  writing,  and  editing.  Finally,  thank  you 
again  to  all  those  who  have  supported  us  through  our  time  at  Naval  Postgraduate  School. 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


I. 


INTRODUCTION 


This  chapter  is  an  introduction  to  Marine  Corps  logistics  modernization  efforts 
and  systems  thinking  methodology.  Section  A  is  an  overview  of  the  logistics  goals 
outlined  in  Expeditionary  Force  21  (EF21).  Section  B  defines  logistics  information 
technology  (Log  IT)  Systems  as  a  capability  to  enable  Marine  logisticians  to  meet  the 
logistics  goals  of  EF21.  Section  C  provides  background  on  systems  thinking 
methodology  and  Section  D  discusses  how  to  use  systems  thinking  methodology  for 
successfully  implementing  logistics  modernization.  The  remainder  of  the  chapter 
provides  the  reader  with  the  problem  and  purpose  statement  along  with  a  scope  in  order 
to  answer  the  research  questions  and  organize  the  thesis  to  comprehensively  address 
this  topic. 

A.  EXPEDITIONARY  FORCE  21 

Expeditionary  Force  21  (EF21)  is  the  Marine  Corps’  capstone  concept  outlining 
the  vision  for  designing  and  developing  a  modernized  force  that  will  be  able  to  overcome 
challenges  Marines  will  face  in  a  future  environment  expected  to  be  both  complex  and 
dynamic  (HQMC,  2014a,  p.  2).  EF21  emphasizes  that,  in  the  future,  Marine  logisticians 
need  to  be  guided  by  two  goals:  1)  support  an  expeditionary  mindset  and  2)  maximize 
organic  capabilities  and  limit  contracting  (HQMC,  2014a,  p.  41).  Marine  logisticians  can 
achieve  these  two  goals  by  changing  how  they  support  the  warfighter  and  by  using 
logistics  information  technology  (Log  IT)  systems  more  effectively. 

EF21  emphasizes  a  light  force  primarily  using  a  responsive  method  of  support 
vice  an  anticipatory  method  in  order  to  reduce  stockpiling  land-based  resources  and 
reduce  burdening  the  supported  unit  with  excess  supplies.  A  responsive  method  of 
support  optimizes  the  resources  on  hand,  and  limits  the  transportation  needed  to  keep 
units  supplied.  To  be  responsive,  and  to  support  an  expeditionary  mindset.  Marine  Corps 
logisticians  must  share  information  across  units  while  reducing  uncertainty  in  a  fluid  and 
complex  environment.  This  requires  Marine  logisticians  having  accurate  near  real-time 
information  to  successfully  accomplish  the  rapid  response  planning  processes  (R2P2)  for 
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operations.  By  using  Logistics  IT  systems  more  effectively  when  planning  and  supporting 
operations,  Marine  logisticians  will  better  support  the  warfighter  and  meet  the  demands 
of  an  expeditionary  mindset  while  maximizing  organic  capabilities.  Log  IT  systems  are 
an  enabling  technology  and  provide  Marine  logisticians  increased  capability  to  meet  the 
goals  of  logistics  modernization  as  outlined  in  EF21. 

B.  LOGISTICS  INFORMATION  TECHNOLOGY  AS  A  CAPABILITY 

Richard  Daft  states  in  his  book  Organization  Theory  and  Design  that  information 
technology  (IT)  provides  many  benefits  to  the  organization  and  has  been  a  crucial  factor 
in  helping  organizations  maintain  their  competitive  edge  in  an  increasing  global 
environment  (Daft,  2013,  p.  309).  When  used  appropriately,  IT  can  improve  decision¬ 
making,  and  enhance  control,  efficiency  and  coordination  of  the  organization  both 
internally  and  externally  (Daft,  2013,  p.  309).  Marine  logisticians  can  improve  their 
planning  by  using  Logistic  IT  systems  to  provide  metrics  on  how  transportation  assets  are 
being  used  at  the  tactical  level. 

Log  IT  systems  are  an  enabling  capability  because  a  Marine  logistician  can  use 
these  tools  to  provide  analytics  that  will  enhance  the  MAGTF  commander’s  decision  and 
actions.  For  example,  transportation  metrics  aggregated  at  the  MAGTF  command 
element  (CE)  provides  the  commander  data  on  how  his  or  her  transportation  assets  are 
being  used  across  the  organization.  If  one  element  of  the  MAGTF  is  more  efficient 
compared  to  the  other  elements  than  the  MAGTF  commander  can  implement  these  better 
processes  across  the  MAGTF  and  increase  the  effectiveness  of  his  organization  as  a 
whole.  Furthermore,  these  analytics  can  be  used  to  change  how  Marine  logisticians 
support  the  warfighter,  which  helps  the  Marine  Corps  to  maintain  their  competitive  edge 
in  a  complex,  dynamic  environment  as  described  in  Expeditionary  Force  21  (EF21). 

Therefore,  modernizing  Marine  logistics  with  respect  to  Fog  IT  systems  as  an 
enabling  capability  is  a  necessary  step  in  meeting  the  vision  of  EF21;  but,  unfortunately, 
logistics  modernization  has  been  a  long,  unsynchronized  process  leading  to  slow, 
sometimes  unsuccessful  change.  Understanding  the  challenges  of  an  unsynchronized 
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approach  to  logistics  modernization,  this  research  implements  a  systems  thinking 
methodology  to  capture  the  process  and  identify  the  levers  needed  for  change. 


C.  BACKGROUND  ON  SYSTEMS  THINKING 

Logistics  modernization  was  meant  to  change  how  Marine  logisticians  use  Log  IT 
systems  in  support  of  their  daily  tasks.  Unfortunately,  implementing  change  within  an 
organization  is  difficult,  especially  an  organization  notorious  for  resistance  to  change 
such  as  the  military.  Change  is  even  more  difficult  to  implement  within  organizations  that 
operate  in  fluid  and  complex  environments  like  those  described  in  EF21.  In  order  to 
reduce  this  complexity,  this  research  applies  a  systems  thinking  approach  to  overcome 
the  challenges  of  modernization  and  meet  the  two  logistics  goals  of  Expeditionary  Force 
21  (EF21):  1)  support  an  expeditionary  mindset  and  2)  maximize  organic  capabilities  and 
limit  contracting  (HQMC,  2014a,  p.  41). 

Systems  thinking  is  a  discipline  used  to  capture  all  of  the  components  within  the 
whole  framework  of  an  organization.  When  applied,  the  systems  design  shows  the 
interrelationships  of  these  different  components  revealing  the  structures  that  underlie 
complex  situations,  and  displaying  which  factors  can  be  leveraged  for  high  or  low  change 
(Senge,  1990,  pp.  68-69).  Within  systems  design,  there  are  multiple  structures  that  can  be 
applied  to  determine  the  degree  of  interrelationships  and  analyze  the  importance  of  each 
factor.  For  this  thesis,  the  researchers  define  the  MAGTF  system  in  terms  of  three 
components:  1)  organization  design,  2)  IT  systems  and  3)  feedback  control.  By  analyzing 
the  interrelationships  of  these  components  and  determining  the  importance  of  each,  the 
researchers  discovered  current  gaps  in  the  MAGTF  system. 

D.  IMPLEMENTING  LOGISTICS  MODERNIZATION 

During  28-31  July  2015,  the  researchers,  Captains  Sarah  Bergstrom  and  Margaret 

Snyder,  observed  internal  organizational  processes  and  interviewed  process  owners  at  I 

MEF  located  at  Marine  Corps  base  (MCB)  Pendleton,  California  in  order  to  study  how 

effectively  I  MEF  was  able  to  implement  FOGMOD  initiatives  published  by  HQMC, 

I&F.  By  observing  several  process  owners  at  the  operational  and  tactical  levels,  the 

researchers  found  that  each  major  subordinate  command  (MSC)  within  I  MEF  used  Fog 
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IT  systems  based  on  the  information  requirements  dictated  by  their  commanders. 
Moreover,  these  Log  IT  systems  were  used  in  a  different  capacity  depending  on  whether 
or  not  the  unit  was  in  a  garrison  or  tactical  environment.  The  researchers  found  that 
implementing  policy  and  guidance  within  the  organization  was  challenging  given  the 
excessive  number  of  Log  IT  systems  available  to  Marine  logisticians  and  the  amount  of 
direction  provided  by  Headquarters  Marine  Corps,  Installations  and  Logistics  (HQMC, 
I&L).  Overall,  this  unsynchronized  process  led  to  slow  change  within  the  organization. 

Therefore,  in  order  to  appropriately  address  the  problem  of  how  logistics 
modernization  is  successfully  implemented  throughout  the  Marine  Corps,  the  researchers 
studied  the  information  gaps  within  the  current  MAGTF  system  by  defining  it  in  terms  of 
organization  design,  IT  systems  and  feedback  control  at  each  level  of  war.  By  addressing 
the  levers  of  change  within  the  organization,  Marine  logisticians  will  better  support  the 
warfighter  and  meet  the  EF21  logistics  goals  across  the  organization  in  a  synergistic 
manner.  With  a  well-defined  process,  the  MAGTF  commander  will  have  increased 
situational  awareness  and  be  enabled  to  make  decisions  based  on  accurate,  near  real  time 
information  provided  by  Fog  IT  systems.  The  MAGTF  commander  will  also  be  able  to 
provide  accurate  reports  to  the  operational  and  strategic  levels  and  receive  better  support 
from  supporting  agencies  based  on  updated  information  on  logistics  capabilities.  This 
thesis  focuses  on  transportation  assets  within  the  MAGTF  to  demonstrate  how  Marine 
logisticians  can  use  Fog  IT  systems  more  effectively  with  feedback  control  at  the 
MAGTF  commander  level. 

E.  PROBLEM  STATEMENT 

The  MAGTF  lacks  decision  support  tools  for  transportation  asset  employment  and 
supply  tracking  visibility  from  subordinate  units.  This  lack  of  visibility  into  transportation 
assets  prevents  tactical  level  commanders  from  making  timely  and  informed  decisions 
required  to  effectively  plan  for  operations.  Marine  logisticians  working  with  multiple  Fog 
IT  systems  experience  reduced  efficiency,  wasted  time,  higher  costs  and  increased  risk  of 
not  supporting  operations  in  an  expeditionary  manner. 
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F.  PURPOSE  STATEMENT 

The  study  developed  a  proof  of  principle  decision  support  dashboard  that 
integrates  relevant  MAGTF  logistics  systems  to  aid  the  tactical  level  commander’s 
decision-making  process  during  sustainment  operations.  The  researchers  also  investigated 
the  feasibility  of  using  rapid  application  development  (RAD)  tool  to  create  web  analytics 
in  order  to  support  the  decision  making  process.  The  potential  benefit  of  this  research  is  a 
methodology  with  associated  application  that  provides  the  MAGTF  the  critical 
information  required  to  make  efficient  decisions  on  the  utilization  of  transportation 
assets. 


G.  SCOPE  AND  METHODOLOGY 

This  section  includes  the  scope  and  methodology.  After  applying  a  methodology, 
the  researchers  present  the  primary  research  questions  that  frame  the  research.  In 
answering  these  research  questions,  the  authors  provide  the  benefits  of  this  study.  Finally, 
the  researchers  provide  the  organization  of  the  thesis  to  give  the  reader  an  outline  of  what 
the  study  will  accomplish. 

1.  Scope 

This  study  concentrates  on  the  Marine  expeditionary  unit  (MEU)  because  the 
MEU  combines  all  the  elements  of  the  MAGTF  in  a  tactical  setting.  Furthermore,  the 
appropriate  subject  is  the  MAGTF  CE  S-4  at  the  MEU  because  this  organization  has  an 
internal  focus  of  supporting  transportation  at  the  tactical  level  and  is  responsible  for 
tracking  transportation  metrics  for  the  MAGTF.  This  thesis  reviews  Log  IT  systems  used 
at  the  tactical  level  of  the  MAGTF  in  order  to  observe  how  effectively  LOGMOD 
initiatives  have  been  implemented  by  the  organization.  Based  on  this  analysis,  the 
researchers  designed  and  developed  a  decision  support  dashboard  that  will  be  used  by  the 
MAGTF  CE  S-4  to  aid  in  decision  making  at  the  tactical  level  for  transportation. 

The  dashboard  will  be  centered  on  a  use  case  provided  by  the  sponsors  that  will 
allow  MAGTF  commanders  to  more  effectively  employ  their  air  and  ground 
transportation  assets  during  sustainment  operations.  The  researchers  accomplished  this  by 
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pulling  data  from  Transportation  Capacity  Planning  Tool  (TCPT)  and  Theater  Battle 
Management  Core  System  (TBMCS)  to  test  metrics  of  performance  and  assess 
transportation  usage.  By  using  metrics  of  performance,  the  MAGTF  commander  will  gain 
a  better  understanding  of  how  well  the  organization  is  performing  its  tasks  based  on 
feedback  provided  by  Log  IT  systems  and  interpreted  by  Marine  logisticians. 

2.  Methodology 

The  methodology  for  this  thesis  includes  the  following  steps: 

•  Conduct  a  literature  review  and  evaluation  of  organizational  design  and 
logistic  IT  systems 

•  Complete  a  requirements/gap  analysis  of  current  Marines  Corps  policy 

•  Determine  organizational  design  and  apply  appropriate  IT  system 

•  Define  metrics  of  performance  for  analyzing  transportation  use  cases 

•  Develop  a  conceptual  dashboard 

•  Assess  the  dashboard 

3.  Primary  Research  Questions 

What  is  the  current  organization  of  the  MAGTF  as  it  relates  to  Log  IT  systems  to 
include  for  example,  roles,  users,  and  functionality?  How  well  can  the  developed 
application  design  use  and  access  existing  logistics  databases?  Through  analytics,  how 
can  we  use  information  from  command  and  control  (C2)  and  in-transit  visibility  (ITV) 
databases  to  effectively  employ  air  and  ground  distribution  of  supplies  to  support  the 
MAGTF? 

4.  Benefits  of  Study 

The  proposed  proof  of  principle  product  provides  the  MAGTF  commander  with  a 

dashboard  to  analyze  the  use  of  both  air  and  ground  transportation  assets  at  the  tactical 

level.  By  having  this  information  readily  available,  a  commander  can  make  decisions  on 

how  to  better  employ  these  assets  to  ensure  equipment  and  supplies  are  being  transported 

in  the  most  effective  and  timely  manner.  Another  potential  benefit  of  integrating  aviation 

and  ground  logistics  systems  is  reducing  the  delivery  time  for  equipment  and  supplies  by 
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more  efficiently  using  available  lift  capability  within  the  MAGTF.  Furthermore,  the 
application  combines  relevant  information  from  multiple  systems  into  one  database, 
which  eliminates  redundancies  in  systems  and  stream-line  decisions  in  regards  to 
logistics  and  supply  management. 

5.  Organization  of  Thesis 

This  thesis  approached  logistics  modernization  from  a  systems  thinking 
perspective  in  order  to  achieve  the  logistics  principles  set  forth  in  EF21.  The  researchers 
have  divided  this  work  in  two  phases.  Phase  one  encompasses  Chapters  II  and  III.  First, 
the  researchers  reviewed  current  logistics  modernization  policies  published  by  the  Marine 
Corps  and  identified  gaps  within  the  current  structure  for  implementing  these  policies. 
Chapter  III  defined  and  applied  a  systems  design  to  the  Marine  air-ground  task  force 
(MAGTF)  in  order  to  identify  the  levers  needed  for  change  within  the  system  and 
provided  a  proposed  systemic  structure  for  analyzing  future  iterations  of  logistic 
modernization  efforts. 

Phase  two  involves  Chapters  IV  and  V.  These  chapters  demonstrate  why  it  is 
essential  to  apply  systems  design  when  using  IT  systems  by  creating  a  proof  of  principle 
transportation  dashboard.  This  dashboard  shows  how  the  Marine  Corps  can  successfully 
implement  change  by  applying  the  appropriate  organizational  design  and  feedback 
mechanisms  to  Log  IT  systems  in  order  to  increase  situational  awareness  at  the  tactical 
level  and  provide  the  information  necessary  for  the  MAGTF  commander  to  make  a 
decision.  Chapter  IV  encompasses  the  development  tools  and  methodology  associated 
with  building  the  proof  of  principle  application.  Chapter  V  describes  the  use  case  and  the 
researchers  demonstrate  how  the  proof  of  principle  application  could  be  used  to  provide 
both  air  and  ground  transportation  metrics  to  the  MAGTF  commander.  Last,  Chapter  VI 
is  a  summary  of  the  research,  including  lessons  learned  and  recommendations  for  future 
research  on  this  topic. 
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II.  LITERATURE  REVIEW  AND  OVERVIEW 
OF  CURRENT  SYSTEM 


This  chapter  is  a  review  of  the  current  policies,  orders  and  strategy  documents  that 
are  used  by  Marine  logisticians  for  logistics  modernization.  This  research  is  valuable 
because  analyzing  the  current  logistics  modernization  efforts  will  allow  the  researchers  to 
identify  gaps  with  the  current  process.  By  identifying  the  gaps,  the  researchers  chose  an 
appropriate  methodology  to  improve  how  the  Marine  Corps  implements  Log  IT  systems, 
which  is  discussed  in  Chapter  III.  Section  A  covers  current  logistics  policy.  Section  B 
discusses  challenges  of  implementation  and  integration  of  both  air  and  ground  systems. 
Section  C  provides  a  gap  analysis  and  recommended  way  forward  based  on  the  literature 
review  of  the  current  system. 

A.  LOGISTICS  MODERNIZATION  POLICY 

In  2005,  the  Marine  Corps  developed  and  published  its  vision  for  logistics 
modernization  (LOGMOD)  via  MARADMIN  444/05  based  on  lessons  learned  from 
Operation  IRAQI  FREEDOM  (OIF)  (HQMC,  2005).  This  vision  aimed  at  several 
initiatives  including  upgrading  the  supply  and  maintenance  systems,  improving 
information  shortfalls,  providing  a  total  asset  and  in-transit  visibility  (ITV)  capability, 
and  streamlining  a  distribution  system  in  order  to  improve  logistics  effectiveness  within 
the  Marine  air- ground  task  force  (MAGTF).  Since  2005,  several  more  policies  and 
Marine  Corps  orders  (MCO)  have  been  written  and  published  in  the  spirit  of  LOGMOD. 
These  policies  include  Marine  administrative  message  (MARADMIN)  444/05,  Marine 
Corps  bulletin  (MCBUL)  4081:  MAGTF  Logistics  Support  Systems  (MLS2),  MCO 
4000.51:  Automatic  Identification  Technology  (AIT),  MCO  4470.1 A:  United  States 
Marine  Corps  (USMC)  MAGTF  Deployment  and  Distribution  Policy  (MDDP),  and 
Logistics  IT  Portfolio  Strategy. 

1.  MARADMIN  444/05 

LOGMOD  concluded  that  legacy  systems  and  stove-piped  information  reduces 
logistics  effectiveness.  MARADMIN  444/05  classified  Global  Combat  Support  System- 
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Marine  Corps  (GCSS-MC)  as  a  critical  Log  IT  system  that  will  overcome  these 
information  gaps.  GCSS-MC  is  an  enterprise  solution  that  has  updated  and  integrated 
multiple  IT  systems  to  improve  Marine  Corps  capabilities.  Using  a  phased  approach, 
GCSS-MC  successfully  replaced  multiple  legacy  systems  and  integrated  functions  of 
logistics,  such  as  supply  and  maintenance  to  facilitate  greater  synergy  at  the  tactical  and 
operational  level.  Initially,  the  Marine  Corps  expected  GCSS-MC  to  be  operationally 
capable  within  seven  years  of  implementation.  However,  GCSS-MC  has  not  reached  full 
maturity  as  of  2015.  As  a  result,  supply  and  maintenance  transactions  are  fully  supported 
by  GCSS-MC,  but  there  is  no  dashboard  that  provides  analytics  on  these  transactions. 
GCSS-MC  also  lacks  the  ability  to  integrate  both  Marine  air  and  ground  transportation 
assets  in  order  to  fully  optimize  lift  capability  and  availability.  In  order  to  overcome  this 
capability  gap,  MARADMIN  444/05  designated  several  Log  IT  systems  as  program  of 
records  until  GCSS-MC  is  fully  capable. 

MARADMIN  444/05  formally  identified  several  systems  within  the  USMC 
Logistics  Information  Systems  portfolio/program  of  records  to  support  increased 
visibility  across  the  battlefield.  These  systems  include:  Battle  Command  Sustainment 
Support  System  (BCS3),  Transportation  Capacity  Planning  Tool  (TCPT)  and  Common 
Logistics  Command  and  Control  System  (CLC2S)  (HQMC,  2005).  While  it  is  recognized 
that  using  multiple  systems  are  not  ideal,  it  is  necessary  that  Marine  logisticians  use  them 
in  the  interim  while  GCSS-MC  is  still  being  developed.  This  policy  was  promulgated  in 
2005  and  is  still  active  until  GCSS-MC  is  capable  of  providing  the  needed  information 
for  Marine  logisticians  to  maintain  situational  awareness  throughout  the  entire 
distribution  network.  These  Log  IT  systems  are  a  necessary  tool  for  Marine  logisticians  to 
properly  plan  for  supporting  tactical  level  operations.  Moreover,  accurate  information  is 
key  to  proper  planning  and  must  be  provided  by  Log  IT  systems  as  designated  within 
MCBUL  4081. 

2.  MCBUL  4081:  MAGTF  Logistics  Support  Systems  (MLS2) 

MCBUL  4081  was  released  in  May  of  2012.  The  purpose  of  the  bulletin  is  to 
provide  guidance  on  approved  MLS2  for  use  within  the  MAGTF.  This  bulletin  contains 
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over  54  Log  IT  systems  and  applications  that  are  used  to  fill  in  information  gaps  essential 
for  Marine  logisticians  to  perform  his  or  her  job  (DON,  2012).  This  is  an  overwhelming 
amount  of  IT  systems  for  any  user  to  monitor.  Additionally,  MCBUL  4081  provides 
definitions  and  capabilities  of  each  Log  IT  system  but  does  not  define  how  these  Log  IT 
systems  will  be  used  within  the  organization  in  support  of  operations.  Figure  1  is  a 
systems  diagram  of  how  MLS2  systems  should  be  used  at  the  tactical  level  provided  by 
the  MLS2  Project  Manager,  Log  IT  Systems,  Marine  Corps  Systems  Command 
(MARCORSYSCOM). 


USMC  Logistics  Systems  Architecture 
(Tactical) 
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Figure  1.  USMC  Logistics  Systems  Architecture. 
Source:  R.  Barber,  personal  communication,  June  30,  2014. 


The  different  components  that  are  included  in  this  systems  diagram  are  Log  IT 
systems,  organization,  and  feedback  loops.  Currently,  this  systems  diagram  is  not 
enforced  as  a  standard  across  the  organization.  This  diagram  is  only  a  recommendation 
on  how  units  should  be  using  their  Log  IT  systems  to  communicate  and  perform  logistical 
functions  in  support  of  operations. 
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3.  MCO  4000.51:  Automatic  Identification  Technology  (AIT) 

MCO  4000.51:  AIT  was  published  in  2013  with  the  purpose  of  establishing  policy 
regarding  the  use  of  AIT  within  the  organization  and  to  define  the  suite  of  technologies 
that  support  automatic  information  systems  (AIS).  According  to  the  AIT  policy,  these 
technologies  include  “linear  barcodes,  two-dimensional  (2D)  barcodes,  magnetic  strips, 
integrated  circuit  chips  (ICC),  optical  memory  cards  (OMC),  radio  frequency 
identification  (RFID)  (active  and  passive),  and  contact  memory  buttons  (CMBs)”  (DON, 
2013,  p.  1).  This  MCO  mandates  which  AIT  is  to  be  used  in  concert  with  AIS  to  capture 
and  transfer  relevant  data  automatically  within  logistics  systems  while  minimizing  human 
interaction.  When  used  appropriately,  AIT  can  reduce  manpower  requirements  for 
tracking  equipment  and  personnel  as  well  as  increasing  situational  awareness  by 
populating  relevant  fields  within  AIS  passively  and  actively. 

While  AIT  is  a  force  multiplier  and  essential  in  the  distribution  process,  this 
policy  does  not  direct  which  AIS  will  be  used  with  AIT.  This  policy  also  does  not 
provide  a  systemic  design  on  implementing  AIT.  For  example,  Commanders  of  Marine 
Corps  Forces  are  each  tasked  with  developing  and  implementing  internal  procedures  to 
mandate  operational  use  of  AIT.  Again,  the  lack  of  standardization  negatively  impacts 
situational  awareness  because  whether  or  not  a  unit  can  capture  relevant  information 
depends  on  whether  or  not  they  use  AIS.  In  addition,  the  individual  commander 
determines  relevant  information,  but  this  information  does  not  necessarily  come  from 
AIT  and  AIS.  For  example,  most  tactical  units  use  Microsoft  Excel  spreadsheets  to  track 
equipment  due  to  reduced  bandwidth  connectivity  while  deployed  in  austere 
environments.  This  practice  does  not  encourage  or  facilitate  the  successful 
implementation  of  MCO  4000.51:  AIT,  nor  does  it  provide  the  necessary  information  for 
the  Marine  Corps  distribution  process  as  described  in  MCO  4470.1 A:  USMC  MAGTF 
Deployment  and  Distribution  Policy  (MDDP). 
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4. 


MCO  4470.1A:  USMC  MAGTF  Deployment  and  Distribution  Policy 
(MDDP) 


Released  in  2014,  MCO  4470.1 A:  USMC  MAGTF  Deployment  and  Distribution 
Policy  (MDDP)  defines  the  roles  and  responsibilities  of  MDDP  elements  to  establish  an 
integrated  method  of  managing  transportation  and  supplies.  This  document  created  a  new 
organization,  the  MAGTF  deployment  and  distribution  operations  center  (MDDOC),  who 
is  given  the  responsibility  to  “conduct  integrated  planning,  provide  guidance,  coordinate, 
and  monitor  transportation  and  inventory  resources  as  they  relate  to  the  management  of 
the  MAGTF’s  distribution  process”  (DON,  2014,  p.  10).  In  order  to  accomplish  these 
tasks,  the  Marine  expeditionary  force  (MEF)  is  tasked  with  creating  standard  operating 
procedures  (SOP)  for  the  MDDOC.  Separate  SOPs  for  each  MEF  does  not  facilitate  a 
streamlined  distribution  system  to  improve  logistics  effectiveness.  Additionally,  the 
MDDOC  serves  to  coordinate  and  monitor  transportation,  but  does  not  have  authority  to 
control  these  separate  unit  movement  control  centers  (UMCC)  at  the  MSC  level  such  as 
the  Marine  air  wing  (MAW). 

5.  Theater  Battle  Management  Core  System  (TBMCS) 

The  Marine  aviation  community  uses  Theater  Battle  Management  Core  System 
(TBMCS)  to  maintain  situational  awareness  of  passengers  and  cargo  moving  via  aircraft 
in  accordance  with  current  wing  procedure  manuals  (WgPM)  such  as  WgPM  3000.1:  3d 
Marine  Air  Wing  (MAW)  Battlestaff  Standard  Operating  Procedure  (SOP)  (2015).  This 
SOP  mandates  the  use  of  this  system  within  the  MAW.  The  tactical  air  command  center 
(TACC)  utilizes  TBMCS  and  is  physically  separate  from  the  ground  logistics  element. 
Within  the  MAGTF,  Air  officers  are  assigned  to  each  of  the  MAGTF  command  elements 
and  provide  guidance  on  how  to  request  Marine  aviation  assets  for  coordinating  activities 
across  the  different  elements  of  the  MAGTF.  Unfortunately,  Air  officers  typically  have 
neither  the  access  to  TBMCS  nor  the  authority  to  task  aircrafts  in  support  of  logistics 
missions.  Furthermore,  TBMCS  is  not  designed  to  provide  transportation  metrics  for 
Marine  logisticians  because  it  is  not  a  designated  Log  IT  system.  As  a  result,  TBMCS  is 
not  aligned  to  the  overall  Log  IT  Portfolio  Strategy  for  modernizing  logistics. 
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6.  Logistics  Information  Technology  (Log  IT)  Portfolio  Strategy 

Accurate  information  is  the  key  to  proper  planning.  The  Marine  Corps  has 
outlined  its  key  objectives  for  improving  information  sharing  through  the  Logistics 
Information  Technology  (Log  IT)  Portfolio  Strategy.  Published  in  2014  by  Deputy 
Commandant,  Installations  and  Logistics  (DCJ&L)  Lieutenant  General  (Lt  Gen) 
Faulkner,  this  policy  is  aimed  at  providing  guidance  on  Log  IT  systems  that  supports  the 
future  operational  requirements  described  in  EF21  within  a  fiscally  constrained 
environment.  These  objectives  include  transitioning  the  logistics  community  into  a 
knowledge-based  element  in  the  Operating  Force  and  Supporting  Establishment  to 
achieve  decision  and  execution  superiority.  The  Marine  Corps  published  its  Log  IT 
Portfolio  Strategy  to  emphasize  that  objectives  will  be  achieved  across  two  main 
components:  1)  MAGTF  logistics  support  systems  (MLS2)  and  2)  enterprise  logistics 
support  systems  (ELS2)  (HQMC,  2014b,  p.  3).  Using  these  two  components  greatly 
enhances  horizontal  communication  across  all  units  and  additionally  provides  a  total  asset 
and  in-transit  visibility  (ITV)  capability. 

The  Log  IT  Portfolio  Strategy  is  an  effort  to  synchronize  efforts  to  modernize 
logistics  processes.  The  key  vision  of  the  document  is  that  Log  IT  systems  can  meet 
emerging  operational  requirements  defined  in  EF21  within  a  fiscally  constrained 
environment  (HQMC,  2014b,  p.  3).  In  order  to  readily  deploy  units,  while  also  managing 
costs,  it  is  essential  that  the  Marine  Corps  establish  an  effective  portfolio  management 
construct  (HQMC,  2014b,  p.  7).  This  vision  aims  to  “achieve  an  interoperable  Log  IT 
portfolio  that  provides  a  more  integrated  and  scalable  end  to  end  logistics  chain 
management”  (HQMC,  2014b,  p.  8)  using  MLS2  so  that  the  right  people  get  the  right 
information  at  the  right  time.  The  Logistics  Plans,  Policy  and  Strategic  Mobility  Division 
are  tasked  with  implementing  this  vision.  While  this  strategy  is  a  step  in  the  right 
direction  towards  effective  management,  it  does  not  include  integrating  IT  systems  for 
Marine  aviation.  Without  integrating  Marine  aviation  at  the  tactical  level,  the  MAGTF 
commander’s  situational  awareness  will  be  impeded  concerning  how  his  transportation 
assets  are  being  used  in  support  of  logistics.  Therefore,  Marine  logisticians  will  still  be 
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limited  to  primarily  conducting  distribution  via  ground  transportation  and  only  requesting 
air  when  required. 

B.  CHALLENGES  OF  IMPLEMENTATION 

An  unsynchronized  approach  to  logistics  modernization  presents  several 
challenges  when  implementing  policies  across  the  organization.  These  challenges  include 
a  lack  of  standard  procedures,  formal  reports  and  integration.  Reviewing  these  challenges 
is  valuable  because  the  researchers  identified  gaps  on  the  current  system  and  recommend 
a  way  forward.  This  analysis  frames  the  discussion  in  Chapter  III,  which  applies  the 
systems  thinking  methodology  and  creates  a  proposed  systemic  structure  in  order  to 
increase  Marine  logistician’s  ability  to  meet  the  logistics  goals  outlined  in  EF21. 

1.  Lack  of  Standard  Procedures 

All  six  of  these  policies  discussed  in  this  thesis  provide  guidance  on  logistical 
processes  and  mandates  which  Log  IT  systems  will  be  used  by  Marine  logisticians  in  a 
centralized  fashion.  However,  these  documents  do  not  provide  a  systemic  approach  on 
how  these  Log  IT  systems  will  be  used  by  Marine  logisticians  at  the  operational  and 
tactical  levels.  Furthermore,  the  researchers  only  analyzed  six  policies  to  provide  the 
reader  an  idea  of  the  issue  but  could  include  several  more  on  the  same  topic.  As  a  result 
of  not  applying  a  systemic  approach,  these  documents  are  not  interrelated  and  could 
potentially  provide  conflicting  guidance.  In  addition,  this  loose  guidance  is  counter  to  a 
strict  mechanistic  design,  which  enforces  rules,  regulations  and  standard  procedures  by 
using  formal  systems  (Daft,  2013,  p.  31).  In  order  to  maintain  continuity,  standardization 
and  facilitate  proper  chain  of  communication  and  guidance,  it  is  necessary  that  formal 
systems  in  place  work  congruently  with  policy.  Without  standard  procedures,  logistics 
modernization  efforts  will  continue  to  be  implemented  in  an  unsynchronized  manner 
across  the  Marine  Corps. 

2.  Lack  of  Formal  Reports 

Furthermore,  some  of  these  Log  IT  systems  have  redundant  capabilities.  This  lack 
of  standardized  processes  increases  the  complexity  in  an  already  dynamic  environment, 
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thus  increasing  uncertainty  in  the  environment.  HQMC,  I&L  is  unable  to  efficiently 
“manage  information,  guide  communication  and  detect  deviations  from  established 
standards  and  goals”  (Daft,  2013,  p.  31)  because  there  are  no  formal  systems  placed  at  the 
operational  and  tactical  levels.  This  thesis  will  review  MLS2  systems  for  transportation  at 
the  tactical  level  because  these  are  systems  that  HQMC,  I&L  has  mandated  to  be  used  at 
the  tactical  and  operational  level  in  accordance  with  LOGMOD  initiatives  until  GCSS- 
MC  is  fully  mature  (HQMC,  2005).  In  particular,  the  MLS2  system  this  thesis  will  study 
is  TCPT.  The  benefit  of  requiring  formal  reports  from  Log  IT  systems  is  that  this 
practice  ensures  and  enforces  that  units  will  use  these  Log  IT  systems  for  tracking  their 
transportation  metrics.  Additionally,  formal  reports  measure  the  established  standards  and 
goals  of  the  strategic  level  (Daft,  2013,  p.  31).  Formal  reports  generated  from  Log  IT 
systems  are  not  a  requirement  in  the  current  Marine  Corps  guidance. 

3.  Lack  of  Integration 

LOGMOD  identified  the  need  to  streamline  the  distribution  system  in  order  to 
improve  logistics  effectiveness  within  the  Marine  air- ground  task  force  (MAGTF). 
According  to  Marine  Corps  doctrinal  publication  (MCDP)  4-0  Logistics,  every  logistics 
system  has  two  fundamental  elements:  a  distribution  network  and  command  and  control 
(C2)  (HQMC,  1997).  Currently,  there  is  no  single  process  owner  for  the  distribution 
network  or  command  and  control  (C2). 

In  order  to  streamline  transportation  and  supply.  Marine  logisticians  must  be  able 
to  use  one  system  to  generate  requirements,  process  requests  and  task  ground  and 
aviation  units  to  support.  Currently,  Marine  logisticians  use  multiple  systems  including 
TCPT,  CLC2S,  and  GCSS-MC  to  monitor  requests  and  task  units  to  support  via  ground 
transportation.  On  the  other  hand,  Marine  aviators  use  TBMCS  to  track  aircraft 
passengers  and  cargo  and  Marine  logisticians  do  not  use  this  system  on  a  daily  basis. 
Multiple  process  owners  further  complicate  streamlining  support  to  the  MAGTF  as  each 
entity  has  competing  requirements  as  well  as  impacting  the  quality  of  information 
processed  in  the  Log  IT  systems. 
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c. 


GAP  ANALYSIS  AND  WAY  FORWARD 


For  this  thesis,  the  researchers  apply  a  systems  thinking  methodology  using  three 
components:  1)  organization  design,  2)  IT  systems  and  3)  feedback  control.  By 
structuring  these  components  across  the  Marine  Corps,  Marine  logisticians  can  achieve 
LOGMOD  initiatives  and  the  two  goals  of  expeditionary  logistics  for  EF21.  This  thesis 
demonstrates  that  applying  a  systems  thinking  approach  will  increase  the  MAGTF 
commander’s  situational  awareness  by  developing  an  application  that  can  be  used  by  the 
MAGTF  CE  S-4.  This  application  will  provide  the  MAGTF  CE  S-4  the  necessary 
information  to  make  a  decision  and  provide  recommendations  on  transportation  assets 
based  on  metrics. 

1.  Gap  Analysis 

Currently,  there  is  no  standard  methodology  the  Marine  Corps  uses  to  assess 
whether  or  not  logistics  modernization  policies  are  successfully  being  implemented 
across  the  organization.  There  is  also  no  standard  structure  that  exists  for  how  the 
different  units  within  the  Marine  Corps  use  Log  IT  systems,  which  creates  gaps  in 
collecting  data  and  providing  analytics  in  meeting  strategic  goals.  Furthermore,  there  is 
no  web  application  that  provides  Marine  logisticians  with  an  integrated  view  of  both  air 
and  ground  transportation  metrics.  Without  this  knowledge,  it  is  difficult  for  Marine 
logisticians  to  properly  plan  and  make  changes  based  on  feedback  concerning  how 
transportation  assets  are  being  used  to  support  the  MAGTF.  This  thesis  addresses  these 
gaps  by  applying  a  systemic  approach  to  the  MAGTF  in  Chapter  III  and  demonstrating 
the  usefulness  of  this  methodology  in  phase  two  of  the  thesis,  which  encompasses 
Chapter  IV  and  Chapter  V. 

2.  The  Way  Forward 

The  proposed  application  developed  in  this  thesis  demonstrates  how  applying  a 
systemic  approach  when  implementing  IT  systems,  promulgating  policy  and  recognizing 
organization  structure  is  necessary  for  organizational  effectiveness  and  efficiencies.  As 
previously  discussed,  the  current  IT  system  structure  was  not  built  with  respect  to  the 

organization  design,  which  creates  gaps  in  the  commander’s  situational  awareness. 
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Therefore,  the  application  model  developed  in  this  thesis  is  a  proof  of  principle  to  provide 
an  integrated  view  for  the  commander  by  pulling  the  necessary  information  from  these 
disparate  IT  systems  at  the  appropriate  level  of  organization.  The  web  application  is  the 
Transportation  Capacity  Tool,  which  pulls  information  from  two  existing  databases, 
TCPT  and  TBMCS,  for  use  at  the  tactical  level.  The  researchers  show  the  usefulness  of 
this  application  in  Phase  two  of  this  thesis  by  studying  a  use  case  centered  on  MAGTF 
transportation  assets,  particularly  air  and  ground  assets.  By  having  access  to  this 
information,  the  application  can  be  used  by  the  MAGTF  commander  to  increase  decision¬ 
making  and  logistics  effectiveness  within  the  organization. 

Chapter  III  provides  the  reader  with  an  introduction  to  systems  thinking 
methodology  and  defines  three  components  that  apply  to  the  MAGTF  system:  1) 
organization  design,  2)  IT  systems  and  3)  feedback  control.  These  components  are 
applied  to  the  different  levels  of  war  and  reveal  the  interrelationships  between  the 
activities,  which  needs  to  be  considered  when  promulgating  policy  or  making  a  change. 
After  defining  the  MAGTF  in  terms  of  a  systemic  approach,  the  researchers  provide  a 
proposed  systemic  structure  that  can  be  used  to  successfully  meet  logistics  modernization 
goals  in  a  more  efficient  and  effective  manner. 
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III.  APPLIED  SYSTEMIC  APPROACH  TO  THE  MAGTF 


This  chapter  approaches  logistics  modernization  from  a  systems  thinking 
perspective  in  order  to  achieve  the  logistics  principles  set  forth  in  EF21.  This  chapter 
addresses  the  three  components  of  the  system:  1)  organization  design,  2)  IT  systems  and 
3)  feedback  control.  Section  A  and  B  define  organizational  design  and  applies  the 
appropriate  design  to  each  level  of  war.  Section  C  reviews  why  it  is  important  to  apply 
the  appropriate  organization  design  when  using  IT  systems  and  Section  D  identifies  the 
specific  IT  systems  that  will  be  used  for  capturing  transportation  metrics.  Section  E 
covers  the  last  component  of  the  systemic  methodology  and  explains  how  feedback 
mechanisms  within  Log  IT  systems  increases  situational  awareness  at  the  tactical  level 
and  provides  the  necessary  information  for  the  MAGTF  commander  to  make  an  enhanced 
decision.  Finally,  Section  F  is  a  proposed  systemic  structure  that  can  be  utilized  for 
implementing  logistics  modernization  efforts  within  the  organization  and  successfully 
meet  Marine  Corps  strategic  goals. 


A.  ORGANIZATION  DESIGN 


In  organizational  theory,  there  are  two  different  design  approaches:  1) 
mechanistic  and  2)  organic.  Figure  2  is  a  diagram  that  depicts  the  characteristics  of 
organization  that  have  mechanistic  and  organic  designs. 


Mechanistic  Design 


Organic  Design 


Typical  Contingency  Factors: 
Large  Size 
Efficiency  Strategy 
Stable  Environment 
Rigid  Culture 

Manufacturing  Technology 


Typical  Contingency  Factors: 
Small  Size 
Innovation  Strategy 
Changing  Environment 
Adaptive  Culture 
Service  Technology 


Figure  2.  Organic  and  Mechanistic  Design.  Source:  Daft  (2013),  p.  31. 
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Using  these  two  different  organizational  designs  applied  to  the  different  levels  of 
war  is  valuable  because  it  ensures  that  the  organization  is  able  to  successfully  meet  their 
goals.  Based  on  the  contingency  factors  of  the  organization,  the  appropriate  design  will 
dictate  which  type  of  IT  system  should  be  used  to  meet  strategic  goals.  For  instance,  the 
mechanistic  design  allows  an  organization  to  operate  more  efficiently,  whereas  an 
organization  that  has  an  organic  design  operates  more  innovatively.  Since  the  Marine 
Corps  operates  and  deploys  in  a  variety  of  environments,  the  researchers  review  the 
benefits  of  each  design  related  to  efficiency  in  the  next  section. 

1.  Organization  Design  Related  to  Efficiency 

Analysis  of  the  hierarchical  structure  reveals  that  the  Marine  Corps  is  inherently 
centralized  in  accordance  with  a  mechanistic  design;  however,  the  MAGTF  is  designed  to 
conduct  decentralized  operations  in  accordance  with  an  organic  design.  Decentralization 
places  decision-making  authority  at  the  lowest  levels  in  order  to  respond  to 
environmental  changes  (Daft,  2013,  p.  30).  Decentralization  also  increases  organizational 
efficiency  because  it  facilitates  rapid  adaption  to  change  (Daft,  2013,  p.  98).  For  an 
organization  to  achieve  its  strategic  objectives,  it  is  important  to  understand  the 
environment  that  influences  the  internal  workings.  Efficiency  as  it  is  related  to  each 
organizational  design  is  shown  in  Figure  3. 


Vertical  Organization 
Designed  for  Efficiency 
(Mechanistic) 


Horizontal  Organization 
Designed  for  Learning 
(Organic) 


Horizontal  structure  is  dominant 

•  Shared  tasks,  empowerment 

•  Relaxed  hierarchy,  few  rules 

•  Horizontal  communication,  face  to  face 

•  Many  teams  and  taskforces 

•  Decentralized  decision  making 


Dominant 

Structural 

Approach  Vertical  structure  is  dominant 


•  Specialized  tasks 

•  Strict  hierarchy,  many  rules 

•  Vertical  communication  and  reporting  systems 

•  Few  teams,  taskforces,  or  integrators 

•  Centralized  decision  making 


Figure  3.  The  Relationship  of  Organization  Design  to  Efficiency  versus  Learning 

Outcomes.  Source:  Daft  (2013),  p.  98. 
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The  MAGTF  operates  in  a  complex  and  highly  unstable  environment,  but  this 
environment  is  further  exacerbated  during  deployment.  Depending  on  the  fluidity  of  the 
deployment,  high  uncertainty  will  pervade  based  on  the  amount  of  information  that  will 
need  to  be  constantly  updated.  An  organization  that  is  successfully  able  to  adapt  to  these 
rapid  changes  will  apply  an  organic  design  instead  of  a  mechanistic  design.  Currently,  the 
Marine  Corps  has  implemented  logistics  modernization  (LOGMOD)  initiatives  and 
passed  guidance  within  its  three  different  levels  of  war:  strategic,  operational,  and  tactical 
without  respect  to  organization  design.  The  next  few  sections  are  an  overview  of  how  the 
current  design  relates  to  the  levels  of  war. 

2.  Strategic  Level 

At  the  strategic  level,  Headquarters  Marine  Corps  (HQMC),  Installations  and 
Logistics  (I&L)  is  responsible  for  disseminating  policies  and  guidance  on  logistics  and 
Log  IT  systems.  HQMC,  I&L  has  published  several  polices  concerning  the  distribution 
process  and  the  use  of  Log  IT  systems  in  accordance  with  the  shared  vision  of  EF21  and 
LOGMOD.  These  policies  include  Marine  administrative  message  (MARADMIN) 
444/05,  Marine  Corps  bulletin  (MCBUL)  4081:  MAGTF  Fogistics  Support  Systems 
(MFS2),  Marine  Corps  order  (MCO)  4000.51:  Automatic  Identification  Technology 
(AIT),  MCO  4470.1 A:  USMC  MAGTF  Deployment  and  Distribution  Policy  (MDDP), 
and  Fogistics  IT  Portfolio  Strategy. 

3.  Operational  Level 

At  the  operational  level,  Marine  expeditionary  forces  (MEF)  are  responsible  for 
creating  standard  operating  procedures  (SOP)  to  implement  these  policies.  Currently, 
within  the  Marine  Corps  there  are  four  different  MEFs  geographically  separated  around 
the  world.  Based  on  these  locations,  the  MEFs  operate  independent  of  one  another  based 
on  the  knowledge  and  experience  of  the  Marines  that  have  been  stationed  at  these  units. 
At  this  level,  the  MEFs  can  use  Fog  IT  systems  as  they  see  fit  as  long  as  they  are  in 
compliance  with  the  published  policy. 
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4. 


Tactical  Level 


At  the  tactical  level,  the  MAGTF  is  responsible  for  executing  tasks  according  to 
the  guidance  provided  by  policy  from  the  strategic  level  and  SOPs  that  are  approved  at 
the  operational  level.  Currently,  the  MAGTF  is  deployed  in  a  standard  structure  that 
include  elements  such  as  the  command  element  (CE),  ground  combat  element  (GCE),  air 
combat  element  (ACE),  and  logistics  combat  element  (LCE).  The  MAGTF  can  be  sized 
accordingly  with  the  need  of  supporting  operations.  At  this  level,  the  MAGTF  has  the 
ability  to  choose  which  Log  IT  systems  they  will  leverage  as  long  as  they  are  in 
compliance  with  the  published  policy  and  meet  the  information  requirements  dictated  at 
the  operational  and  strategic  levels. 

B.  APPLYING  ORGANIZATIONAL  DESIGN  TO  LEVELS  OF  WAR 

This  section  defines  the  different  levels  of  war  in  terms  of  organization  design. 
This  provides  the  reader  an  idea  of  how  Log  IT  systems  can  be  used  to  meet  logistics 
modernization  goals  by  implementing  the  appropriate  design.  The  two  organizational 
designs  are  mechanistic  and  organic  (Daft,  2013,  p.  31).  The  authors  apply  these  two 
designs  to  the  strategic,  operational  and  tactical  level  of  war  and  discuss  the  flaws  of  not 
applying  a  mechanistic  or  organic  design  to  the  organization. 

1.  Mechanistic  Design 

As  depicted  in  Figure  2,  a  mechanistic  design  is  defined  by  a  centralized  structure. 
As  such,  the  organization  operates  with  a  strict  hierarchy  of  authority  through  vertical 
communication.  The  mechanistic  design  has  many  rules  that  are  formalized  through 
guidance.  Last,  a  mechanistic  design  has  units  with  specialized  tasks  that  remains  in  a 
stable  environment.  The  contingency  factors  for  a  mechanistic  design  are  large  size  with 
a  stable  environment  and  rigid  culture  (Daft,  2013,  p.  31).  Based  on  this  definition,  the 
researchers  apply  this  design  to  the  strategic  and  operational  levels  of  war. 

a.  Strategic  Level 

At  the  strategic  level,  the  Marine  Corps  is  a  large,  centralized  organization  with 
vertical  information  flow  and  a  strict  hierarchy  of  authority.  The  Marine  Corps  has  many 
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rules,  which  are  formalized  over  policy  and  guidance.  All  of  these  characteristics  mean 
that  at  the  strategic  level  the  Marine  Corps  has  a  mechanistic  design.  An  organization 
with  a  mechanistic  design  publishes  guidance  from  the  top-down.  When  implementing 
change,  the  top-down  management  will  create  a  vision  as  a  solution  to  the  problem.  In  his 
book,  The  Fifth  Discipline ,  author  Peter  Senge  (1990)  asserts,  “[  h  Juiiding  shared  vision 
must  be  seen  as  a  central  element  of  the  daily  work  of  leaders”  (p.  214)  because  it 
provides  purpose  and  core  values  to  the  organization.  Shared  vision  is  a  product  of  key 
stakeholders  across  all  levels  of  the  organization,  but  it  is  not  always  shared  nor 
implemented  successfully. 

b.  Operational  Level 

At  the  operational  level,  there  are  many  different  organizations  within  the  Marine 
Corps  such  as  the  Marine  expeditionary  force  (MEF)  or  the  Marine  component  command 
within  a  geographic  command.  This  study  reviews  the  MEF  in  relation  to  the  MEU. 
According  to  MCO  4470.1 A,  the  MEF  is  tasked  with  providing  standard  operating 
procedures  (SOP)  for  its  subordinate  commands  to  ensure  that  the  distribution  process  is 
successfully  executed  at  the  tactical  level.  In  addition,  the  MEF  is  tasked  with  training, 
staffing  and  equipping  the  MAGTF  deployment  and  distribution  operations  center 
(MDDOC)  to  implement  policy  (DON,  2014). 

This  direction  is  structurally  complex  because  the  Marine  Corps  is  organized  into 
four  different  MEF  commands  that  are  each  tasked  with  publishing  separate  SOPs.  In 
order  to  successfully  implement  change,  the  policies  and  procedures  need  to  be 
standardized  in  a  hierarchical  structure  due  to  high  uncertainty  of  information  received 
across  the  organization  in  accordance  with  a  mechanistic  design  (Daft,  2013,  p.  98).  Also, 
the  mechanistic  design  requires  that  HQMC,  I&L  provide  a  standardized  formal  system 
to  support  efficiency  as  competing  requirements  will  impede  future  funding  for  logistics 
modernization  (Daft,  2013,  p.  98). 

Future  funding  of  Log  IT  systems  is  dependent  on  performance  of  the  system. 
This  is  difficult  to  capture  because  each  MEF  uses  the  MLS2  systems  in  a  different 
manner  and  may  prefer  one  Log  IT  systems  to  another.  This  practice  of  MEF’s 
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customizing  the  use  of  MLS2  systems  within  the  MAGTF  will  adversely  impact  future 
funding  for  Log  IT  systems  as  contracts  are  renewed  or  re-competed  according  to  each 
MEF’s  preferences  and  recommendations.  On  the  other  hand,  rather  than  continuing  to 
facilitate  each  MEF’s  customization  of  Log  IT  systems,  these  funds  could  be  reallocated 
to  further  develop  GCSS-MC  into  a  more  effective  tool  for  Marine  logisticians  vice  other 
MLS2  systems. 

2.  Organic  Design 

An  organic  design  applied  to  the  Marine  Corps  at  the  tactical  level  increases 
efficiency.  As  developed  by  Daft  (2013),  “an  organic  design  is  characterized  by  a 
decentralized  structure,  empowered  roles,  informal  systems,  horizontal  communication 
and  collaborative  teamwork”  (p.  36).  Daft  (2013)  lists  the  contingency  factors  of  an 
organic  design  as  “small  size,  innovation  strategy,  changing  environment,  adaptive 
culture  and  service  technology”  (p.  31)  Essentially,  the  MAGTF  is  a  decentralized 
structure  of  the  Marine  Corps  because  it  is  comprised  of  the  essential  elements  to 
successfully  accomplish  its  mission  with  little  outside  support.  The  MAGTF  contains  the 
command  element  (CE)  who  tasks  and  collaborates  with  the  air  combat  element  (ACE), 
logistics  combat  element  (LCE)  and  the  ground  combat  element  (GCE)  to  achieve  their 
mission. 


a.  Tactical  Level 

The  MAGTF  is  the  organization  at  the  tactical  level  of  war.  The  MAGTF  is  the 
organization  that  will  be  executing  the  distribution  and  transportation  process  using 
written  policy  to  perform  their  daily  functions  in  accordance  with  guidance  received  from 
the  MAGTF  commander.  The  MDDOC  is  the  entity  that  will  be  providing  this  function 
for  the  MAGTF.  MCO  44170.1 A  provides  an  organizational  diagram  of  how  the 
MDDOC  should  be  structured  within  a  garrison  and  deployed  environment.  The  structure 
for  the  deployed  MDDOC  is  included  as  Appendix  A  for  reference.  This  diagram  is 
extremely  useful  as  it  provides  a  standard  structure  so  that  each  MEF  can  provide  the 
same  information  across  the  same  levels. 
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Standardization  makes  it  easier  for  information  to  be  collected  at  the  strategic  and 
operational  level  of  war  and  used  for  analysis  in  order  to  make  the  distribution  process 
more  effective  and  efficient.  However,  the  organizational  diagram  in  Appendix  A  has 
some  flaws.  For  example,  MEF’s  are  not  mandated  to  follow  this  structure  as  it  is  a 
recommendation  only.  Additionally,  this  organizational  diagram  does  not  provide  a 
systemic  framework  of  components  such  as  the  horizontal  and  vertical  interrelationships 
with  the  tactical  units  and  the  Log  IT  systems  that  each  element  uses  for  performing  their 
function.  Therefore,  it  is  difficult  to  pinpoint  which  levers  of  the  system  will  need  to  be 
adjusted  based  on  lack  of  information  flow  and  feedback  mechanisms.  The  next 
subsection  reviews  why  applying  the  organic  design  at  the  tactical  level  for  the  MAGTF 
provides  many  benefits  to  the  commander. 

b.  MAGTF 

The  MAGTF  does  operate  with  collaborative  teamwork  because  the  ACE,  LCE 
and  GCE  all  interact  with  the  CE  and  each  other  in  order  to  accomplish  their  tasks. 
Empowered  roles  are  encouraged  at  the  MAGTF  as  units  typically  have  decreased  layers 
of  hierarchy  in  order  to  get  the  support  necessary  to  conduct  operations  in  a  rapid  manner. 
Horizontal  communication  refers  to  the  communication  that  happens  across  the 
organization.  This  also  occurs  at  the  MAGTF  as  the  ACE,  GCE  and  LCE  have  special 
relationships  to  provide  support  to  one  another.  A  prime  example  of  this  is  the  direct 
support  (DS)  combat  logistics  battalion  (CLB)  and  the  regimental  combat  team  (RCT). 
This  information  flow  is  horizontal  because  each  entity  is  working  together  to  accomplish 
the  same  goals  during  an  operation  without  having  to  get  direction  or  approval  from  the 
CE  in  a  vertical  fashion. 

Finally,  an  organic  design  has  few  rules  and  is  informal.  This  is  also  true  of  the 
MAGTF  to  an  extent.  While  the  MAGTF  does  have  a  formal  SOP  that  describes  the 
internal  workings  of  the  unit,  the  SOP  constantly  is  being  refined  based  on  what  works 
and  the  organizational  and  personal  relationships  developed  during  the  deployment.  The 
MAGTF  uses  collaborative  teamwork  and  horizontal  communication  when  developing 
internal  and  external  working  relationships.  In  this  sense,  the  MAGTF  is  extremely 
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adaptive  because  it  follows  the  organic  design  (Daft,  2013,  p.  31).  The  MAGTF  also 
shares  many  of  the  contingency  factors  of  an  organic  design. 

As  previously  listed  by  Daft  (2013),  the  contingency  factors  for  an  organic  design 
are  “small  size,  innovation  strategy,  changing  environment,  adaptive  culture  and  service 
technology'’  (p.  31).  The  MAGTF  is  unique  since  it  can  be  sized  according  to  the  need, 
although  generally  small  in  nature  to  enhance  flexibility.  The  MAGTF  is  innovative 
when  overcoming  challenges.  For  example,  the  proof  of  principle  (PoP)  applied  by  the 
11th  MEU  reduced  the  customer  wait  time  by  introducing  a  new  distribution  liaison  cell 
(DLC)  to  improve  material  throughput.  The  MAGTF  is  constantly  changing  their 
environment  through  deployment  or  crisis  response.  Based  on  an  organic  design,  the 
MAGTF  will  employ  a  service  technology  for  Log  IT  systems,  which  is  characterized  by 
intangible  outputs,  rapid  response  times  and  the  importance  of  the  human  element 
amongst  other  characterizations  (Daft,  2013,  p.  277). 

C.  IT  SYSTEMS  APPLIED  TO  ORGANIZATIONAL  DESIGN 

Since  the  MAGTF  has  an  organic  design  and  the  type  of  technology  that  is 
appropriate  to  meet  the  environmental  demands  is  a  service  technology,  the  system 
thinker  must  consider  how  the  factors  of  organizational  design,  environment  and 
technology  are  interrelated.  These  factors  are  interrelated  using  logistics  information 
technology  (Log  IT)  that  is  relationally  structured  based  on  the  MAGTL  design.  In 
Marine  logistics,  MCBUL  4081  provides  a  list  of  54  different  Log  IT  systems  that  are 
used  for  tracking  logistical  functions.  Organization  efficiency  is  defined  as  the  amount  of 
resources  used  to  produce  a  unit  of  output  within  the  internal  workings  of  an  organization 
(Daft,  2013,  p.  71).  In  order  for  an  organic  design  to  be  efficient,  it  is  imperative  that  the 
organization  reduces  the  amount  of  IT  systems  that  are  in  use. 

The  MAGTL  could  reduce  the  amount  of  Log  IT  systems  it  uses  for  logistics,  but 
this  needs  to  be  facilitated  by  the  operational  and  strategic  levels  through  updated  policy, 
procedures  and  Marine  Corps  orders  (MCO).  Lor  example,  HQMC  released 
MARADMIN  331/15  in  July  of  2015  and  recently  mandated  that  all  requirements  for 
materials  and  services  will  be  ordered  by  all  units  using  GCSS-MC  or  purchase  request 
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builder  (PRB)  in  order  to  improve  visibility  and  accountability  of  requisitions  (HQMC, 
2015).  This  is  an  improvement  in  increasing  effectiveness;  however,  units  can  still 
request  services  and  supplies  through  CLC2S  and  TCPT  instead  of  GCSS-MC.  In  order 
to  be  most  effective  across  the  organization,  GCSS-MC  needs  to  be  further  developed  to 
facilitate  units  ordering  all  classes  of  supply  using  only  one  system  that  captures 
information  requirements. 

The  Log  IT  system  needs  to  be  built  in  order  to  facilitate  the  organizational 
design.  This  research  aims  to  create  a  dashboard  using  the  Log  IT  systems  in  place  to 
gather  information  on  transportation.  This  research  is  focused  on  transportation  at  the 
MAGTF  level  because  this  is  an  opportunity  to  provide  greater  enhancements  to 
horizontal  communication  across  the  organization  at  the  tactical  level  as  dictated  by  an 
organic  design.  The  specific  elements  that  will  be  enhanced  are  ground  and  air 
transportation  as  a  result  of  increasing  horizontal  communication  from  the  ACE,  GCE 
and  LCE  using  a  dashboard.  This  will  facilitate  greater  situational  awareness  at  the 
tactical  level.  Moreover,  this  research  aims  to  measure  how  effectively  the  stakeholders 
will  use  this  Log  IT  system  specifically  the  MAGTF  CE  S-4  since  he  or  she  will  benefit 
most  from  an  application  that  provides  transportation  metrics. 

D.  IT  SYSTEMS  FOR  TRANSPORTATION 

Given  the  amount  of  Log  IT  systems  identified  as  MLS2  within  MCBUL  4081, 
this  research  is  appropriately  scoped  to  only  include  relevant  Log  IT  systems  used  for 
capturing  transportation  within  a  MAGTF.  At  a  minimum,  the  researchers  have  identified 
the  following  Log  IT  systems  for  transportation  as  CLC2S,  TCPT  and  GCSS-MC  as 
these  systems  are  designated  MLS2  and  critical  components  of  the  logistics  operational 
architecture  (Log  OA).  By  integrating  the  aviation  component,  the  researchers  have  also 
identified  TBMCS  as  an  IT  system  that  will  need  to  be  monitored  for  tracking  cargo  and 
passengers  transported  on  Marine  aviation  assets  at  the  tactical  level.  The  intent  of  this 
section  is  to  provide  an  overview  of  the  capabilities  and  limitations  of  each  of  these 
systems  to  the  warfighter  within  the  context  of  the  Log  OA. 
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1. 


GCSS-MC 


GCSS-MC  is  considered  to  be  the  practical  implementation  of  the  Marine  Corps’ 
Log  OA,  which  standardizes  the  implementation  of  Marine  Corps-wide  processes  for 
logistics  and  related  IT  enablers.  It  is  also  an  enterprise  system,  which  is  defined  as  “a  set 
of  information  systems  tools  that  many  organizations  use  to  enable  information  flow 
within  and  between  processes  across  the  organization”  (Pearlson  &  Saunders,  2013,  p. 
1 10).  As  an  enterprise  system,  GCSS-MC  should  be  the  only  Log  IT  system  that  users 
need  to  access  for  information;  unfortunately,  GCSS-MC  is  still  being  developed  and 
future  increments  will  provide  these  capabilities.  As  a  result  of  future  planned 
development,  Marine  Logisticians  currently  use  GCSS-MC  coupled  with  the  53  other 
MLS2  systems  to  support  operations  (DON,  2012). 

GCSS-MC  includes  many  features  that  are  beneficial  for  the  Marine  logistician, 
but  it  also  needs  to  be  improved.  According  to  the  24th  MEU,  GCSS-MC  was  a  secondary 
means  of  ordering  high  priority  material  because  of  connectivity  issues  and  reduced 
functionality.  For  example,  Marines  on  the  USS  NEW  YORK  did  not  have  GCSS-MC 
functionality  60  days  into  the  deployment,  greatly  reducing  their  ability  to  perform 
decentralized  tasks  within  the  Log  IT  system  and  negatively  impacting  their  situational 
awareness  (24th  MEU,  2015).  Additionally,  Marines  cannot  use  GCSS-MC  on  a  SECRET 
network,  which  is  not  conducive  to  maintaining  an  advantage  over  potential  adversaries. 
Based  on  these  two  reasons,  this  research  focuses  on  demonstrating  how  the  MAGTF  CE 
S-4  can  use  TCPT  and  TBMCS  as  a  means  for  providing  transportation  analytics. 

2.  MLS2  Systems 

Both  TCPT  and  CLC2S  are  designated  MLS2  systems  and  are  viable  systems  for 
use  by  Marine  Logisticians.  Both  of  these  Log  IT  systems  can  be  used  on  a  SECRET 
network  and  can  provide  automated  reports  based  on  what  the  user  needs.  Individual 
MAGTFs  can  determine  which  system  they  prefer  to  use,  but  most  units  typically  use 
both  systems.  Most  units  use  both  systems  because  all  of  these  systems  combined  give 
the  commander  more  information.  Furthermore,  both  of  these  Log  IT  systems  are 
advertised  as  a  tool  to  provide  the  commander  a  logistics  dashboard  to  aid  in  decision- 
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making.  Both  Log  IT  systems  can  also  be  used  with  GCSS-MC  to  provide  the  user  with 
increased  functionality  (DON,  2012).  For  the  purposes  of  this  research,  the  authors  have 
scoped  the  use  case  to  only  include  information  pulled  from  TCPT  from  the  MLS  2  suite 
of  systems  because  this  Log  IT  system  provides  more  detailed  information  on 
transportation  metrics.  When  used  in  conjunction  with  TBMCS,  the  commander  will  get 
a  more  accurate  picture  of  the  organic  transportation  assets  with  the  least  amount  of 
systems. 


3.  TBMCS 

Last,  this  research  focuses  on  using  TBMCS  within  the  MAGTF  CE  S-4  because 
this  is  the  IT  system  used  by  the  Marine  air  wing  (MAW).  TBMCS  is  useful  because  it 
provides  information  on  passengers  and  cargo  traveling  via  Marine  aircraft.  Additionally, 
it  produces  the  air  tasking  order  (ATO),  which  can  be  used  by  the  MAGTF  CE  S-4  to 
move  high  priority  items  on  short  timelines  or  it  can  be  used  to  track  and  verify  cargo  and 
passengers  moving  on  Marine  aircraft.  Another  advantage  is  TBMCS  is  a  joint  system 
and  is  used  on  a  SECRET  network.  In  short,  having  access  to  this  IT  system  provides 
Marine  logisticians  another  tool  for  successfully  supporting  the  warfighter  in  a  deployed 
environment. 

For  instance,  the  24th  MEU  CE  successfully  leveraged  organic  MEU  aviation 
assets  by  coordinating  face  to  face  with  the  Navy  and  24th  MEU  ACE  in  formal  meetings. 
As  a  result  of  increased  situational  awareness,  the  24th  MEU  increased  throughput  and 
alleviated  cargo  buildup.  The  24th  MEU  CE  also  reduced  the  amount  of  time  for  moving 
high  priority  items  by  reviewing  flight  schedules,  conducting  prior  coordination  with  the 
MEU  ACE  and  leveraging  the  MV-22  Osprey  which  is  an  aircraft  characterized  by  its 
superior  speed  and  range  (24th  MEU,  2015).  While  formal  meetings  are  beneficial,  the 
MAGTF  CE  S-4  will  be  better  able  to  plan  in  advance  and  coordinate  with  the  MAGTF 
ACE  by  having  access  to  TBMCS.  Furthermore,  the  MAGTF  CE  S-4  could  use  TBMCS 
in  order  to  have  access  to  the  most  updated  information  on  air  operations  thereby 
facilitating  enhanced  decision-making. 
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4.  Importance  of  Metrics 

Using  IT  systems  provides  Marine  logisticians  accurate  and  updated  information 
quickly,  which  is  critical  for  planning  operations  and  managing  resources.  By  ensuring 
the  MAGTF  CE  S-4  appropriately  leverages  these  IT  systems,  Marines  will  become  more 
effective  and  efficient  logisticians  in  a  MEU  environment  as  mandated  in  EF21.  In  order 
to  appropriately  leverage  these  systems,  strategic  and  operational  guidance  needs  to 
establish  metrics  of  performance  for  the  tactical  level.  As  stated  in  the  24th  MEU  after 
action  report  (AAR),  metrics  of  performance  were  key  to  ensuring  Marines  at  the  tactical 
level  could  monitor,  assess  and  improve  performance  during  the  deployment  (24th  MEU, 
2015).  Therefore,  it  is  necessary  to  define  the  last  component  of  the  MAGTF  system: 
feedback  control. 

E.  FEEDBACK  CONTROL  MODEL 

The  purpose  of  the  feedback  control  model  is  to  determine  whether  or  not  the 
organization  meets  established  standards  to  attain  their  goals  (Daft,  2013,  p.  314).  The 
diagram  depicted  in  Figure  4  are  the  inputs  necessary  for  an  organization  to  consider 
when  taking  corrective  action  and  adjusting  goals  (Daft,  2013,  p.  314). 


1.  Set  strategic  goals 

ft 

4.  Take  corrective  action  as 
needed 


2.  Establish  metrics  and 
standards  of  performance 


l 

3.  Compare  metrics  of 

actual  performance  to 
standards 

Figure  4.  A  Simplified  Feedback  Control  Model.  Source:  Daft  (2013),  p.  314. 
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Within  the  Marine  Corps,  LOGMOD  initiatives  are  the  overall  strategic  goals  as 
established  by  HQMC,  I&L  through  several  policies  and  Marine  Corps  orders  (MCO), 
which  is  step  one  of  the  feedback  control  model.  Unfortunately,  strategic  goals  are  the 
extent  of  the  feedback  control  model  for  the  MAGTF.  Applying  the  feedback  control 
model  to  the  MAGTF,  there  are  no  formally  established  metrics  and  standards  of 
performance,  which  is  step  two  of  the  model.  Without  these  metrics,  Marine  logisticians 
at  the  tactical,  operational  and  strategic  level  will  not  be  able  to  compare  performance 
and  take  corrective  action  as  needed  for  steps  three  and  four  of  the  model.  Without  the 
ability  to  compare  performance  output  to  take  corrective  action,  organizational  efficiency 
will  be  impeded  and  change  cannot  be  implemented  successfully.  To  be  successful, 
leadership  will  need  to  be  involved  in  receiving  and  providing  recommendations  on 
feedback  and  by  using  defined  metrics  of  performance. 

Metrics  of  performance  are  essential  in  changing  an  organization.  A  successful 
example  of  this  is  the  11th  MEU  deployment  from  July  2014  to  February  2015  using 
customer  wait  time  as  a  metric  of  performance.  Working  with  HQMC,  I&L  the  1 1th  MEU 
implemented  a  proof  of  principle  and  changed  their  structure  in  order  to  better  handle 
material  throughput  using  distribution  liaison  cells  (DLC).  Using  customer  wait  time,  the 
11th  MEU  realized  that  by  placing  DLC  Marines  at  key  logistics  infrastructure  nodes 
ahead  of  schedule  they  were  able  to  reduce  customer  wait  time.  According  to  the  11th 
MEU  Post  Deployment  Brief,  customer  wait  time  for  priority  02  items  were  reduced  from 
an  average  of  45  days  down  to  8  days  and  priority  05  items  were  reduced  from  an 
average  of  90  days  down  to  19  days  (personal  communication,  2015).  Due  to  the  organic 
design  of  the  MEU,  11th  MEU  was  able  to  change  their  structure  and  adapt  to  the 
environmental  changes  rapidly.  Also,  the  informal  structure  gave  them  the  ability  to  use 
their  Marines  in  a  different  manner  than  previous  MEUs.  This  is  an  excellent  example  of 
a  unit  with  an  organic  design  using  information  from  Log  IT  systems  as  metrics  of 
performance  and  analyzing  the  appropriate  levers  of  change  within  the  organizational 
system. 

The  11th  MEU  was  able  to  successfully  change  by  embracing  the  qualities  of  an 
organic  design;  however,  this  change  may  be  only  effective  for  the  duration  of  the  1 1th 
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MEU  deployment  if  it  is  not  formally  captured  through  standard  operating  procedures. 
Therefore,  learning  in  the  organization  is  might  be  only  effective  for  each  individual  unit 
because  change  is  not  formalized  for  successive  MEUs.  Learning  is  encouraged  in  an 
organic  design  and  is  facilitated  with  decentralization  but  learning  is  counter  to  a 
mechanistic  design  and  impeded  with  centralization.  In  order  to  effectively  meet 
LOGMOD  initiatives  as  published  by  HQMC,  I&L,  it  is  necessary  to  apply  a  systems 
approach  and  leverage  the  appropriate  levers  within  the  construct  once  these  levers  are 
identified. 

F.  PROPOSED  SYSTEMIC  STRUCTURE 

Tying  all  of  these  concepts  together  and  applying  a  systemic  approach  to  the 
MAGTF,  the  researchers  developed  a  proposed  systemic  structure  in  order  to  successfully 
meet  logistics  modernization  goals.  This  systemic  structure  includes:  1)  organizational 
design  applied  to  each  level  of  war,  2)  IT  systems  and  3)  feedback  control.  Figure  5  is  a 
proposed  systemic  structure  for  the  MAGTF  system. 


Set  strategic  goals  and  publish  in  policy 
Establish  standard  metrics  and  publish  in  policy 


Measure  metrics 
Compare  metrics 

Take  corrective  action  as  needed  informally 


Figure  5.  Proposed  Systemic  Structure.  Source:  Capt  Sarah  Bergstrom,  2015 
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As  shown  in  Figure  5,  an  organizational  design  applied  with  respect  to  the  IT 
system  at  each  level  of  war  facilitates  rapid  vertical  and  horizontal  communication  within 
the  organization.  Furthermore,  the  IT  system  can  be  used  to  provide  feedback  at  each 
level  of  war,  which  is  valuable  for  assessing  logistics  modernization  efforts. 

Within  the  framework  of  this  proposed  systemic  structure,  this  research  focuses 
on  the  MAGTF  CE  S-4  located  within  the  MEU  in  order  to  measure  metrics  of 
transportation  for  both  air  and  ground  assets.  These  metrics  will  be  compared  and  the 
MEU  can  adapt  to  the  situation  and  take  corrective  actions  as  needed.  By  using  Log  IT 
systems  to  measure  these  metrics,  the  MAGTF  CE  S-4  will  be  more  effective  in  using 
transportation  assets.  Also,  by  establishing  formal  reports  the  Marine  Corps  will  increase 
vertical  communication  from  the  tactical  to  the  strategic  level. 

Integrating  both  air  and  ground  transportation  assets  from  multiple  IT  systems,  the 
Marine  Corps  will  increase  both  horizontal  communication  and  situational  awareness 
across  the  organization.  Once  positive  change  occurs  at  the  tactical  level,  the  Marine 
Corps  can  successfully  implement  these  changes  through  the  strategic  and  operational 
levels  in  a  centralized  fashion,  which  in  turn  promotes  learning  and  improvement  meeting 
the  objectives  of  logistics  modernization  and  the  logistics  goals  of  EF21.  The  researchers 
have  demonstrated  that  these  objectives  can  be  achieved  through  a  systems  thinking 
methodology,  which  is  phase  one  of  this  thesis. 

Phase  two  is  the  demonstration  of  this  proposed  systemic  structure  through  a 
proof  of  principle  web  application.  The  proof  of  principle  web  application  combines  air 
and  ground  transportation  assets  and  provides  the  MAGTF  commander  with 
transportation  metrics.  Chapter  IV  discusses  the  development  tools  used  to  create  the 
application.  Chapter  V  implements  the  web  application  through  a  use  case  provided  by 
the  sponsor  that  is  based  on  a  MEU  scenario.  Based  on  the  feedback  provided  by  the  web 
application,  the  MAGTF  commander  is  enabled  to  use  his  or  her  transportation  assets 
more  effectively  and  efficiently  thereby  achieving  the  objectives  of  logistics 
modernization. 
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IV.  DEVELOPMENT  TOOLS  AND  APPLICATION 

METHODOLOGY 


The  next  section  of  this  thesis  is  the  second  phase  in  which  the  researchers 
develop  a  proof  of  principle  web  application  that  combines  air  and  ground  transportation 
assets.  The  purpose  of  this  application  is  to  show  how  a  dashboard  can  increase 
horizontal  communication  within  the  organization  and  provide  greater  situational 
awareness  for  the  commander.  This  application  meets  the  goals  of  the  feedback  control 
model  because  it  measures  and  compares  metrics  to  allow  for  corrective  action.  The 
development  and  testing  of  this  application,  the  Transportation  Capacity  Tool,  will  be  the 
focus  of  the  following  two  chapters. 

In  this  chapter,  the  researchers  discuss  the  Oracle  products  used  to  develop  and 
test  the  application.  These  products  were  selected  based  on  their  availability,  ease-of-use, 
and  reusability,  as  well  as  Oracle  products  being  used  throughout  the  Marine  Corps.  This 
chapter  is  organized  into  five  parts:  Section  A  provides  background  information  on  the 
Oracle  company;  Section  B  summarizes  the  Oracle  Fusion  platform  to  include 
applications,  middleware  and  architecture;  Section  C  discusses  the  structured  query 
language  (SQL)  developer;  Section  D  discusses  JDeveloper  along  with  the  application 
development  framework  (ADF)  model;  and  Section  E  discusses  the  WebLogic  server. 

A.  ORACLE  BACKGROUND 

Oracle  began  as  a  database  software  company  and  has  emerged  into  a  leader  in 
cloud  applications,  platform  services  and  engineered  systems  that  provide  the  customer 
with  a  fully  packaged  bundle  that  simplifies  portions  of  their  IT  systems  (Hurd,  2014,  p. 
4).  Oracle  was  founded  in  1977  with  the  development  of  the  first  version  of  Oracle 
Database  (Oracle,  2007,  p.  26).  Within  six  years,  Oracle  released  the  first  relational 
database  management  system  (RDBMS)  that  would  run  on  mainframes,  minicomputers 
and  personal  computers  (Oracle,  2007,  p.  29).  Throughout  the  1980’s,  Oracle  continued 
to  revolutionize  the  database  industry  with  the  first  RDBMS  to  operate  in  a  client/server 
environment  (Oracle,  2007,  p.  29).  As  Oracle  progressed  in  the  database  industry,  they 
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saw  a  need  for  enterprise  applications  that  could  utilize  the  Oracle  Database.  In  1990, 
Oracle  introduced  their  first  application  release  that  was  an  accounting  program  that 
leveraged  the  new  client/server  computing  environment  (Oracle,  2007,  p.  30).  Over  the 
next  couple  of  decades,  Oracle  continued  to  improve  on  their  database  and  application 
technologies  with  advanced  features  and  increased  security.  Oracle  earned  the  industry’s 
first  independent  security  evaluation,  which  it  has  maintained  for  decades,  providing 
customers  the  assurance  of  its  secure  environment  from  a  third-party  agency  (Oracle, 
2007,  p.  30).  With  all  the  advancements  and  leading-edge  technology,  Oracle  is  being 
used  by  98%  of  Fortune  500  companies  throughout  the  world  (Oracle,  2016b). 

The  Marine  Corps  has  used  Oracle  products  on  numerous  occasions,  but  most 
notably  as  the  foundation  for  GCSS-MC  (Oracle  AppAdvantage,  2013,  p.  29).  As 
discussed  in  the  previous  chapter,  GCSS-MC  is  the  Marine  Corps’  logistics  IT  system 
that  integrated  a  multitude  of  legacy  IT  systems  in  order  to  improve  their  ability  to  plan 
and  execute  logistical  support  missions.  The  Marine  Corps  did  this  by  leveraging  Oracle 
Fusion  Middleware  and  Oracle  E-Business  Suite  applications  to  consolidate  over  200 
legacy  IT  systems  into  one  integrated  infrastructure  (Oracle  AppAdvantage,  2013,  p.  29). 

B.  ORACLE  FUSION 

Oracle  Fusion  is  a  term  used  to  describe  Oracle’s  overarching  standard 
technology  stack  that  was  built  to  support  the  next  generation  of  business  applications 
(Ronald,  2011,  p.  5).  Oracle  Fusion  is  not  a  product  or  service,  but  rather  a  framework 
that  encompasses  three  pillars  of  technology  used  to  support  applications  deployed  by 
businesses  (Ronald,  2011,  p.  5).  These  pillars  include  Oracle  Fusion  Applications,  Oracle 
Fusion  Middleware,  and  Oracle  Fusion  Architecture  and  are  used  in  conjunction  with 
each  other  in  order  to  support  all  aspects  of  developing,  deploying,  securing,  and 
managing  applications  (Ronald,  2011,  p.  5).  In  using  Oracle  Fusion,  developers  have  only 
one  framework  with  which  to  work  eliminating  redundancy  when  using  multiple  products 
and  ensuring  interoperability  throughout  the  entire  development  process. 
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1.  Oracle  Fusion  Applications 

Fusion  applications  are  business  tools  produced  by  Oracle  that  provide  customers 
with  the  ability  to  manage  different  areas  including  “Customer  Relationship 
Management,  Financial  Management,  Governance,  Risk  and  Compliance,  Human  Capital 
Management,  Procurement,  Project  Portfolio  Management,  and  Supply  Chain 
Management”  (Ronald,  2011,  p.  5).  These  tools  are  offered  as  modules  and  can  be 
purchased  by  a  customer  based  on  their  needs.  Oracle  also  provides  tools  that  allow 
businesses  to  develop  their  own  applications  to  fit  their  needs.  Those  applications 
produced  utilizing  Oracle  technologies  are  also  considered  a  Fusion  application  and  are 
developed  and  deployed  in  the  same  manner  as  Oracle’s  business  tools  (Ronald,  2011,  p. 
5).  The  ability  to  build  your  own  applications  easily  is  especially  intriguing  to  unique 
organizations  such  as  the  Marine  Corps.  The  missions  and  tasks  that  the  Marine  Corps’ 
applications  need  to  accomplish  are  not  normally  found  in  out-of-the-box  solutions. 
Therefore,  the  ability  to  customize  applications  to  fit  the  Marine  Corps’  needs  is  essential 
to  mission  success.  The  application  built  for  this  thesis  would  be  considered  a  Fusion 
application  and  is  thus  supported  by  Oracle  Fusion. 

2.  Oracle  Fusion  Middleware 

In  order  to  properly  run  a  Fusion  Application,  Oracle  needed  to  provide  the 
customer  with  the  infrastructure  to  develop  and  deploy  the  applications.  The  Oracle 
Fusion  Middleware  is  the  platform  on  which  all  Fusion  Applications  run  and  it  provides 
the  customer  with  features  such  as  application  servers,  security,  and  management 
capabilities  (Ronald,  2011,  p.  5).  These  features  support  the  user  through  all  phases  of  the 
application  life-cycle  which  reduces  the  cost  and  complexity  of  building  applications. 
The  middleware  supports  both  Oracle  produced  Fusion  applications  and  customer-built 
applications  (Ronald,  2011,  p.  5).  Figure  6  is  an  overview  of  the  Fusion  Middleware 
platform. 
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Figure  6.  Overview  of  the  Fusion  Middleware  Solution.  Source:  Oracle  (2010). 

3.  Oracle  Fusion  Architecture 

Oracle  Fusion  Architecture  refers  to  the  “blueprints”  used  to  build  Fusion 
applications  on  top  of  the  Fusion  middleware  (Ronald,  2011,  p.5).  The  architecture 
combines  various  technology  principles  to  include  service-oriented  architecture  (SOA) 
and  Java  Platform,  Enterprise  Edition  (Java  EE)  in  which  Fusion  Applications  are  built 
(Ronald,  2011,  p.  5).  By  providing  this  architecture  openly  to  the  public,  developers  have 
a  well-established  and  sophisticated  foundation  on  which  to  build,  greatly  reducing 
interoperability  problems  while  running  applications  in  Oracle  or,  in  conjunction  with 
third-party  platforms. 

C.  SQL  DEVELOPER 

Oracle  SQL  Developer  is  a  development  tool  for  the  Oracle  RDBMS 
environment.  The  SQL  Developer  module  was  developed  to  be  used  by  a  user  at  any 
level  and  provides  a  graphical  user  interface  that  improves  productivity  and  simplifies 
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database  tasks  (Oracle,  2008,  p.  1).  SQL  Developer  was  developed  in  Java  and  can  be 
operated  on  Windows,  Linux  or  Mac  OS  X  making  it  a  valuable  tool  for  developers  in 
different  environments  (Oracle,  2008,  p.  1).  This  tool  allows  a  user  to  connect  to 
databases,  view,  create  and  modify  database  objects,  and  run  SQL  statements  with  ease 
(Oracle,  2008,  p.  2).  This  thesis  required  the  researchers  to  extract  schemas  and  data  from 
two  different  databases  and  combine  them  into  one.  Using  SQL  Developer  made  this 
process  extremely  easy  because  of  its  detailed  user  interface,  help  features,  and  data 
modeler  feature.  The  researchers  were  able  to  gain  a  better  understanding  of  how  both 
TCPT  and  TBMCS  databases  were  structured  and  functioned  by  using  SQL  Developer. 
Figure  7  is  the  SQL  Developer  main  window’s  default  settings  that  can  be  customized 
based  on  user  needs. 
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Figure  7.  SQL  Developer  Main  Window.  Source:  Oracle  (2013). 


D.  JDEVELOPER 

Oracle  JDeveloper  is  a  graphical  interface  tool  used  as  the  development 
environment  for  Oracle  Fusion  Middleware  in  which  Fusion  applications  are  built.  It 
integrates  features  from  Java,  mobile,  web  services,  and  databases  into  one  tool  that 
covers  the  full  development  lifecycle  of  an  application  (Oracle,  2015,  p.  1).  JDeveloper 
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provides  extensive  features  that  support  the  writing,  building  and  deployment  of  Java  and 
web  based  programs  (Ronald,  2011,  p.  10).  JDeveloper  is  a  free  tool  and  its  user-friendly 
interface  provides  a  simple  environment  to  build  applications.  JDeveloper  uses  the  ADF 
framework  for  the  basis  of  application  building.  Figure  8  is  a  depiction  of  the  JDeveloper 
integrated  development  environment  (IDE). 


Figure  8.  JDeveloper’ s  Integrated  Development  Environment. 

Adapted  from:  Ronald  (201 1). 


E.  ADF 

Historically,  the  more  complex  the  application,  the  more  complexity  required  to 
build  it.  Today,  Oracle’s  ADF  framework  allows  users  to  build  extremely  powerful  Java 
EE  based  applications  with  significantly  reduced  effort  (Oracle,  2011,  p.  1).  The  ADF 
framework,  which  is  employed  in  JDeveloper,  introduces  visual  and  declarative  methods, 
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along  with  the  traditional  way  of  building  code,  to  build  applications  (Oracle,  2011,  p. 
2.).  This  allows  users  to  utilize  any  or  all  methods  to  build  applications  depending  on 
their  skill  level  and  abilities. 

The  ADF  framework  implements  the  Model-View-Controller  architecture,  which 
separates  the  application  into  three  layers.  The  ADF  framework  further  separates  the 
model  layer  into  a  business  services  layer  and  a  model  layer.  The  model  layer  presents 
the  data  associated  to  the  current  page  being  accessed  by  binding  it  to  the  Business 
Services  layer  (Gordon  et  al,  2011,  p.  54).  The  Business  Services  layer  provides  access  to 
the  data  source  as  well  as  implements  business  logic  (Gordon  et  al,  2011,  p.  54).  The 
view  layer  exposes  the  business  services  to  the  end-user  through  a  graphic  user  interface 
(Ronald,  2011,  p.  12).  The  controller  layer  represents  the  navigation  of  events  and  pages 
through  the  application  (Ronald,  2011,  p.  12).  This  architecture  gives  users  the  ability  to 
work  on  each  layer  separately  which  simplifies  application  maintenance  and  allows  for 
reuse  of  components  across  multiple  applications  (Oracle,  2011,  p.  3).  For  example,  an 
application  could  consist  of  multiple  pages  that  all  require  a  similar  feature  such  as  login. 
The  user  can  build  a  login  task  flow  which  encompasses  aspects  from  all  layers  and  reuse 
this  feature  on  all  pages.  This  greatly  reduces  development  time  but  also  improves 
maintenance.  The  user  would  only  need  to  update  the  login  task  flow  and  it  would  be 
updated  throughout  the  entire  application  where  that  task  flow  is  used.  Figure  9  is  the 
basic  concept  of  the  ADF  framework. 


Figure  9.  ADF  Framework  Architecture.  Source:  Gordon  et  al  (201 1). 
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1. 


The  Business  Layer 


The  user  builds  this  layer  by  using  ADF  business  components,  which  are  prebuilt 
and  based  on  best  practices  for  database-centric  services  (Gordon  et  al,  2011,  p.  55). 
These  components  provide  the  user  with  the  ability  to  query,  update,  insert  and  delete 
data  while  maintaining  the  integrity  of  the  database  business  rules  (Gordon  et  al,  2011,  p. 
55).  The  three  main  components  are  entity  objects,  view  objects,  and  the  application 
module. 


a.  Entity  Objects 

Entity  objects  are  used  to  represent  a  row  in  a  database  table  while  capturing  the 
business  logic  to  ensure  rules  established  in  the  database  are  being  followed  (Gordon  et 
al,  2011,  p.  55).  Similar  to  a  database  schema,  entity  objects  are  associated  with  one 
another,  which  replicates  the  relationships  established  between  tables  in  the  database 
(Gordon  et  al,  2011,  p.  55).  Once  entity  objects  are  built  and  associations  are  created, 
they  can  be  reused  in  multiple  applications  that  require  access  to  the  same  data. 

b.  View  Objects 

View  objects  represent  a  SQL  query  that  can  join,  filter,  sort,  and  combine  data 
into  a  view  that  is  required  by  the  end  user  or  the  task  being  accomplished  (Gordon  et  al, 
2011,  p.  55).  View  objects  use  the  SQL  language  and  can  be  pull  data  from  multiple 
entity  objects  at  once.  View  objects  are  then  linked  to  one  another  with  view  links  in  a 
similar  fashion  to  linking  tables  in  a  database.  The  user  has  the  ability  to  create  complex 
master-detail  hierarchies  of  view  objects  using  view  links  to  represent  information 
as  needed  for  the  end-user  (Gordon  et  al,  2011,  p.  56).  When  an  end-user  modifies  data 
through  the  graphical  user  interface,  the  view  objects  work  with  the  entity  objects 
to  ensure  the  information  is  validated  and  then  saved  in  the  database  (Gordon  et  al,  2011, 
p.  56). 


c.  Application  Modules 

The  application  module  is  a  transactional  element  that  defines  the  updatable  data 


model  to  the  user  (Gordon  et  al,  2011,  p.  56).  The  view  objects  are  represented  in  the 
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application  module  and  provides  the  user  with  the  ability  to  browse  and  modify  data 
(Gordon  et  al,  2011,  p.  56).  Once  a  user  creates  view  objects,  the  application  module  is  a 
great  tool  to  test  and  validate  the  functionality  of  the  view  objects  and  corresponding 
view  links  before  binding  them  to  pages.  Figure  10  provides  the  reader  an  overview  of 
the  three  major  business  components  used  in  the  business  service  layer. 
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Figure  10.  ADF  Business  Components.  Source:  Gordon  et  al  (2011). 


2.  The  Model  Layer 

The  model  layer  connects  the  business  services  to  the  objects  as  they  are  used  in 
the  other  layers  by  using  data  controls.  Data  controls  are  a  Java  standard  that  use  the 
metadata  interfaces  to  abstract  the  technology  of  a  business  service  to  define  the 
properties,  methods  and  types  of  data  involved  (Gordon  et  al,  2011,  p.  57).  In  JDeveloper, 
this  information  is  shown  as  icons  that  can  be  dragged  and  dropped  onto  a  page  at  which 
time  JDeveloper  will  automatically  create  the  bindings  between  the  page  and  the  service 
(Gordon  et  al,  2011,  p.  57).  This  layer  provides  a  separation  from  the  view  layer  so  that 
all  attributes  and  actions  of  a  business  service  are  viewed  in  a  consistent  way  (Ronald, 

2011,  p.  12). 
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3. 


The  Controller  Layer 


The  controller  layer  is  a  management  layer  that  regulates  page  navigation  and 
flow.  The  ADF  controller  within  JDeveloper  allows  the  user  to  create  reusable  task  flows 
and  page-fragments,  which  can  be  used  separately  or  nested  within  themselves  (Gordon 
et  al,  2011,  p.  57).  Essentially  a  user  can  create  multiple  pages  and  functionalities  on  the 
main  page  of  an  application  by  nesting  task  flows  that  contain  their  own  sets  of  navigable 
pages  (Gordon  et  al,  2011,  p.  57).  This  feature  provides  maximum  flexibility  and 
reusability  for  a  developer  while  allowing  them  to  fully  control  the  flow  of  the 
application.  Figure  1 1  is  an  example  of  a  task  flow  that  could  be  found  in  an  application. 
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Figure  11.  Task  Flow.  Source:  Gordon  et  al  (2011). 

4.  The  View  Layer 

The  View  Layer  represents  the  user  interface.  ADF  Faces  Rich  Client  (ADF 
Faces)  is  the  technology  used  in  the  view  layer  to  build  browser-based  interfaces  (Ronald, 
2011,  p.  15).  ADF  Faces  provides  over  100  components  that  include  data  tables,  tree 
menus,  dividers,  tables,  and  data  visualization  components  such  as  graphs  and  gauges 
(Gordon  et  al,  2011,  p.  58).  ADF  Faces  components  have  a  rendering  kit  built  in  which 
controls  the  display  of  the  component  and  the  JavaScript  that  produces  the  component 
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(Gordon  et  al,  2011,  p.  58).  Having  these  features  built  into  the  drag  and  drop 
components  allows  users  to  build  complex  applications  without  extensive  knowledge  on 
how  each  component  operates  (Gordon  et  al,  2011,  p.  58). 

Oracle  JDeveloper  and  the  ADF  Framework  provides  a  user  with  all  the 
technology  and  standards  needed  to  build  a  rich  application  without  high-level  coding  or 
programming.  The  simplicity  at  each  layer  allows  a  user  to  create  complex  queries, 
integrated  pages  and  visually  appealing  applications  in  a  time  constrained  environment. 
Figure  12  is  the  overall  architecture  of  the  ADF  framework  provided  by  Oracle. 
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Figure  12.  Oracle  ADF  Architecture.  Source:  Ronald  (2011). 


F.  WEBLOGIC  SERVER 

Oracle  Weblogic  Server  is  an  application  server  that  can  be  used  to  control  the 
employment  of  ADF  applications  (Gordon  et  al,  2011,  p.  1297).  Weblogic  server 
implements  all  Java  EE  standard  application  program  interfaces  (APIs)  which  allows  for 
applications  to  “access  databases,  messaging  services  and  connections  to  external 
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enterprise  systems”  (Fusion  Middleware  Understanding  Oracle  Weblogic  Server,  2016,  p. 
1).  Within  JDeveloper,  a  user  can  deploy  an  application  to  the  Integrated  WebLogic 
server  as  a  way  to  test  and  debug  prior  to  full  implementation  of  the  application  (Gordon 
et  al,  2011,  p.  1296).  Weblogic  server  provides  a  robust,  secure  and  highly  scalable 
environment  for  enterprises  to  deploy  mission-critical  applications  (Oracle,  2016a,  p.  1). 
It  also  provides  diagnostic  tools  that  allow  administrators  to  monitor  and  alter 
applications  automatically  (Oracle,  2016a,  p.  1).  Lastly,  Weblogic  server  provides 
expansive  security  features  to  protect  services  and  data  while  preventing  malicious 
attacks  (Oracle,  2016a,  p.  1).  These  features  are  extremely  useful  to  a  user  because  it 
eliminates  the  need  to  purchase  or  develop  their  own  security  functions  and  management 
tools.  Figure  13  is  a  depiction  of  how  the  Weblogic  Server  fits  into  the  Fusion 
Middleware  platform. 


Figure  13.  WebLogic  Server.  Source:  Oracle  (2016a). 
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G.  SUMMARY 

The  Oracle  brand  provides  a  multitude  of  products  that  can  be  used  to 
successfully  and  easily  develop  and  deploy  applications  that  support  business  services. 
The  Fusion  Middleware  bundles  the  above  mentioned  products  into  one  integrated  and 
cohesive  unit  allowing  the  user  to  have  control  over  all  aspects  of  the  development 
process.  Each  one  of  these  services  was  used  in  this  thesis  when  developing  the 
Transportation  Capacity  Tool.  By  leveraging  Oracle’s  services,  the  researchers  were  able 
to  explore  the  databases  required,  conceptualize  and  develop  a  functioning  application 
and  deploy  it  through  Weblogic  server  to  test  its  functionality.  The  development  process 
used  by  the  researchers  will  be  discussed  in  Chapter  V. 
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V.  USE  CASE  AND  APPLICATION  OUTLINE 


This  chapter  describes  the  application  development  process  used  by  the 
researchers.  First,  the  researchers  provide  background  information  on  how  the  concept  of 
the  application  was  established,  followed  by  a  description  of  the  scenario  used  as  a  use 
case.  Next,  the  researchers  explain  the  development  process  and  how  the  Oracle  services 
discussed  in  Chapter  IV  were  utilized  to  build  the  application.  Following  this  explanation 
is  a  depiction  of  the  proof  of  principle  web  application  to  include  design  and 
functionalities  of  each  page.  Lastly,  the  researchers  discuss  possible  future  iterations  for 
this  application. 

A.  INTRODUCTION 

Through  research  and  discussions  with  the  Marine  Corps’  sponsors,  the 
researchers  developed  the  idea  of  an  application  that  combined  information  from  multiple 
databases  onto  one  platform.  After  examining  numerous  logistical  related  databases,  the 
researchers  chose  to  utilize  TCPT  and  TBMCS  to  produce  the  analytics  necessary  for  the 
proof  of  principle  application.  TCPT  is  a  web-based  application  used  to  plan,  manage, 
and  execute  ground  transportation  and  engineering  missions  (DON,  2012).  TBMCS  is  a 
command  and  control  system  comprised  of  eight  separate  schemas  that  is  used  across  all 
services  to  securely  plan  and  manage  the  execution  of  air  missions  (Collens  &  Krause, 
2005,  p.  5). 

This  application  is  intended  to  combine  transportation  asset  usage  from  both 
aviation  and  ground  units.  There  are  two  main  objectives  for  this  application.  First,  the 
application  captures  mission  data  related  to  both  air  and  ground  missions  to  provide  a 
snapshot  of  missions  executed  by  each  unit  on  different  dates.  This  provides  the 
commander  with  the  background  information  on  the  missions  to  reduce  the  need  to  toggle 
between  other  systems.  The  second  objective  is  to  analyze  the  performance  of  the  mission 
by  calculating  the  usage  rate  for  each  individual  asset.  Mission  data,  to  include  the  usage 
rate,  for  air  and  ground  missions  are  not  usually  available  in  one  location  as  the  air 
missions  are  tracked  by  the  operations  section  and  the  ground  missions  are  tracked  by  the 
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logistics  section.  When  the  air  and  ground  logistical  support  mission  and  analysis  is 
combined  into  one  view,  the  commander  is  able  to  analyze  the  performance  of  all 
transportation  assets,  not  just  one  platform. 

B.  USE  CASE 

The  Marine  Corps  sponsors  provided  the  scenario  used  as  a  use  case  for  this 
application.  It  is  based  on  a  Marine  expeditionary  brigade  (MEB)  scenario  in  which  two 
separate  MEU’s  are  tasked  with  conducting  air  and  ground  support  operations  for  troops 
located  at  different  locations.  The  two  MEU’s  are  located  at  separate  sea  bases  and  troops 
operate  from  separate  landing  zones  (LZ).  In  this  scenario,  the  MEB  commander  has 
control  over  the  11th  and  24th  MEUs  as  they  conduct  sustainment  operations.  The 
application  provides  the  MEB  commander  with  the  appropriate  information  for  air  and 
ground  missions  that  were  conducted  by  all  units  that  are  subordinate  to  both  MEUs.  This 
gives  the  MEB  commander  better  situational  awareness  on  how  to  maneuver  and  task  the 
subordinate  units  to  more  effectively  conduct  logistical  support  missions.  Figure  14  is  a 
depiction  of  the  scenario. 


LZ  O  CO  f.  BIT  2/6  24  MEU  110 

Sjgonclk  11  MEU  CE  11  MEU 

Seabase  20nm  off-shore  |  Djibouti  mmeuce  2«meu 


Figure  14.  MEB  Scenario.  Adapted  from:  Marine  Corps  Sponsors  and  Capt  Snyder  (2016). 
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C.  APPLICATION  DEVELOPMENT  PROCESS 

This  section  describes  the  Oracle  products  used  to  build  the  application.  This 
section  also  discusses  the  process  used  to  extract  and  load  the  data,  the  revision  of  ER 
diagrams  from  the  databases  and  the  application  page  layout. 

1.  Products  Utilized 

The  researchers  leveraged  the  Oracle  products  discussed  in  Chapter  IV.  SQL 
Developer  was  used  to  capture,  view,  and  analyze  the  databases  and  corresponding  data. 
This  allowed  the  researchers  to  modify  any  “dirty  data,”  capture  table  relations,  and 
determine  which  tables  and  attributes  would  be  needed  for  the  application.  The 
researchers  then  used  JDeveloper,  along  with  the  ADF  framework,  to  design  and  develop 
the  application.  Lastly,  the  application  was  deployed  in  the  Weblogic  Server  environment 
in  order  to  test  its  functionality.  All  of  these  services  are  encompassed  within  the  Oracle 
Fusion  Middleware  architecture. 

2.  Database  Extraction/Insertion 

The  researchers  received  SQL  scripts  for  the  TCPT  and  TBMCS  databases,  which 
included  all  tables,  primary  and  foreign  keys,  constraints,  and  data.  These  scripts  were 
inserted  into  SQL  Developer  in  order  to  view  and  manipulate  the  information.  The  TCPT 
scripts  provided  a  robust  collection  of  data  from  over  3000  units  across  the  Marine  Corps. 
The  TBMCS  scripts,  however,  did  not  include  any  mission  related  information.  This  is 
likely  due  to  the  fact  that  this  system  is  deployed  on  a  secure  network.  The  researchers 
developed  over  900  lines  of  data  that  created  150  complete  air  missions  in  order  to 
supplement  the  insufficient  data  from  the  TBMCS  scripts.  The  data  created  was  relevant 
to  scenario  described  above. 

One  of  the  main  intentions  of  this  application  was  to  ensure  redundant  work  was 
not  required  by  the  end-user.  For  example,  the  current  structure  would  require  an  end- 
user  to  extract  data  from  TCPT  and  TBMCS  separately  and  then  compile  into  one  report 
to  analyze.  It  is  important  to  the  development  of  this  application  that  when  this 
application  pulls  information  from  the  two  systems,  the  end-user  does  not  have  to  do  any 
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additional  work.  Therefore,  in  an  effort  to  utilize  the  existing  data  sets  as  much  as 
possible,  additional  tables  or  attributes  were  not  added  to  the  schemas. 

3.  Reviewing  Schemas  and  Data 

First,  all  tables  and  data  were  inserted  into  the  researcher’s  Oracle  database 
instance  via  SQL  Developer.  Second,  the  researchers  reviewed  the  data  to  determine 
which  tables  and,  more  specifically,  which  attributes  were  needed  to  produce  the  required 
analytics.  SQL  Developer  was  used  to  reengineer  entity  relationship  (ER)  model 
diagrams  in  order  to  have  a  visual  model  of  how  all  tables  are  related  to  each  other  in  the 
database.  The  ER  diagrams  for  the  tables  used  from  TCPT  and  TBMCS  are  shown  in 
Figures  15  and  16. 


Figure  15.  ER  Diagram  for  TCPT 


Figure  16.  ER  Diagram  for  TBMCS 
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4. 


Designing  the  Application 


After  determining  which  information  was  required  from  the  schemas,  the 
researchers  developed  a  mock  story  board  of  how  the  application  would  function.  This 
was  used  to  brief  the  sponsors  and  receive  feedback  on  how  the  application  should  be 
designed.  Once  agreed  upon,  the  layout  of  pages  was  developed  in  JDeveloper  using  the 
task  flow  manager.  Figure  17  is  the  final  task  flow  of  pages  used  in  the  application. 


Figure  17.  Transportation  Capacity  Tool  Application  Task  Flow. 

The  application  consists  of  five  pages:  1)  Home,  2)  Air,  3)  Ground,  4)  Combo  and 
5)  Combo  Totals.  Each  page  is  described  in  more  detail  in  this  chapter.  When  designing 
the  application  in  JDeveloper,  the  researchers  ensured  the  user  interface  was  simple  to 
use  and  provided  graphics  that  could  be  easily  interpreted  and  presented  to  a  commander. 
The  researchers  developed  the  application  using  the  visual  method  in  JDeveloper  almost 
exclusively,  without  manually  changing  any  code.  In  doing  so,  this  application  could 
easily  be  recreated.  A  full  list  of  setup  instructions  can  be  found  in  Appendix  D. 
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D.  PAGE  DESIGNS/FUNCTIONALITIES 


The  application  has  three  main  segments,  which  include  an  air,  ground  and 
combo.  All  three  segments  can  be  accessed  from  the  home  page  and  through  links  on 
each  subsequent  page.  The  following  sections  describe  each  page  layout  and  the 
functionalities  within  the  application. 

1.  Home  Page 

The  home  page  is  a  generic  page  that  provides  access  to  each  of  the  different 
pages  through  use  of  navigation  buttons.  These  buttons  also  exist  on  all  other  pages  to 
allow  the  end-user  to  navigate  between  each  platform  quickly  without  the  need  to  return 
to  the  homepage.  Figure  18  is  the  design  of  the  home  page. 


Transportation  Capacity  Tool 


Air 


Ground 


Combo 


Figure  18.  Transportation  Capacity  Tool  Application  Home  Page. 

2.  Air  Page 

The  end-user  can  navigate  to  the  air  page  by  clicking  on  the  “Air”  button  located 
on  the  home  page.  Once  at  the  Air  page,  the  end-user  is  able  to  navigate  through  all  air 
units  using  the  navigation  panel  under  the  “Unit”  section.  Once  a  unit  is  selected,  the  end- 
user  can  then  navigate  to  different  mission  dates  under  the  “Date”  section.  When 
navigating,  the  end-user  sees  all  missions  completed  on  that  particular  date  under  the 
“Mission”  section.  Figure  19  is  a  screenshot  of  an  air  mission  conducted  on  January  1, 
2015. 
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Figure  19.  Transportation  Capacity  Tool  Application  Air  Page. 


The  Mission  section  provides  the  end-user  with  the  mission  identification  (ID) 
number,  the  air  battle  plan  (ABP)  identification,  assault  support  request  (ASR)  number, 
and  the  mission  category.  The  section  also  provides  a  transient  attribute  that  calculates 
the  total  mission  usage  rate  and  represents  the  rate  with  the  usage  meter.  The  “Mission 
Details”  section  provides  the  end-user  with  more  information  that  is  derived  from  the 
ASR,  which  includes  the  unit  supported,  takeoff  and  landing  locations,  aircraft  type,  and 
quantity.  The  section  also  takes  information  about  each  aircraft  type  located  in  the 
database  and  calculates  the  total  usage  based  on  the  capabilities  of  the  aircraft.  In  the 
example  shown  above,  the  ASR  requested  to  move  900  pounds  of  cargo  internally  and  23 
passengers.  Based  on  known  aircraft  capacity  data  located  in  the  database,  the  transient 
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attribute  calculated  the  internal  cargo  capacity  at  4%  used  and  96%  of  the  passenger 
capacity  used.  Thus,  in  this  example,  the  mission  resulted  in  a  100%  usage  rate. 

While  this  application  provides  raw  data  and  calculations,  there  are  often 
situations  in  which  the  numbers  do  not  properly  reflect  the  objective  of  the  mission.  In 
some  cases,  the  end-users  will  have  to  revert  back  to  the  actual  ASR  and  mission  data  to 
interpret  the  results.  This  could  include  missions  that  involve  hazardous  material,  specific 
ammunition  or  medical  evacuation  types  of  missions.  In  those  cases,  the  analytic  results 
may  show  low  usage  rates  and  will  need  further  interpretation  provided  to  the 
commander. 


3.  Ground  Page 

The  ground  page  is  designed  in  a  similar  fashion  to  the  air  page.  Figure  20  is  a 
screenshot  of  a  mission  conducted  on  January  8,  2015. 


Figure  20.  Transportation  Capacity  Tool  Application  Ground  Page. 

The  end-user  would  navigate  through  units  and  mission  dates  the  same  way  as  the 


air  page.  The  “Mission”  section  provides  the  end-user  with  the  mission  ID,  destination, 
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mission  distance  (miles),  number  of  vehicles  and  the  total  usage  rate  for  the  entire 
mission.  Ground  transportation  usage  can  be  depicted  in  two  different  ways,  by  weight 
and  by  space.  Each  vehicle  type  has  a  weight  capacity  and  a  space  capacity.  Depending 
on  what  information  is  recorded  in  TCPT,  the  mission  usage  rate  can  vary. 

The  “Mission  vehicle”  section  provides  information  for  each  vehicle  used  in  the 
mission  to  include  Master  ID,  Equipment  ID  and  nomenclature,  and  detailed  information 
about  the  cargo  transported.  Each  individual  vehicle’s  usage  rate  is  calculated  and  are 
combined  to  generate  the  total  mission  usage,  which  is  visible  in  the  “mission”  section. 
Similar  to  the  air  page,  there  is  information  within  the  database  about  each  vehicle  type. 
Each  vehicle  type  has  the  ability  to  transport  different  cargo  types.  For  example,  a  7-ton 
truck  can  move  one  International  Organization  for  Standardization  (ISO)  container,  four 
quadruple  containers  (QUADCONs),  or  16  warehouse  pallets.  Therefore,  the  database 
must  provide  the  capabilities  of  each  vehicle  for  each  cargo  type.  The  application  will 
then  calculate  the  usage  rate  based  on  the  capacity  of  the  vehicle  and  the  cargo 
transported. 

As  seen  in  the  example  from  Figure  20,  the  cargo  type  is  “other”.  The  selection  of 
“other”  in  the  cargo  type  was  an  issue  seen  throughout  many  entries  in  TCPT.  There  are 
options  for  nearly  all  types  of  cargo  being  transported,  yet  “other”  was  selected  for 
multiple  entries.  The  cargo  type  should  identify  whether  the  cargo  is  an  ISO  container, 
pallet,  six  container  (SIXCON),  QUADCON,  passengers,  etc.  When  “other”  is  recorded 
in  the  system  by  the  TCPT  end-user,  the  application  cannot  determine  the  space  capacity. 
In  this  case,  the  application  will  only  calculate  the  usage  rates  based  on  passengers  and 
weight,  if  those  fields  were  entered.  Using  the  “other”  cargo  type  is  an  example  of  dirty 
data  and  can  lead  to  a  misinterpretation  of  data.  For  example,  if  a  7-ton  is  transporting  an 
empty  ISO  container,  the  weight  usage  rate  may  reflect  poorly  because  it  will  be 
significantly  less  than  a  7-ton’s  weight  capacity.  However,  a  7-ton  can  only  transport  one 
ISO  container  at  a  time  therefore  would  reach  its  space  capacity.  If  the  cargo  type  was 
selected  as  “other”  than  the  space  usage  rate  could  not  be  calculated.  Dirty  data  is 
discussed  in  Chapter  V. 
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This  figure  is  a  mission  that  includes  more  than  one  vehicle. 

Figure  21.  Transportation  Capacity  Tool  Application  Ground  Page 

As  a  reminder,  there  are  often  times  when  further  interpretation  is  required  to  gain 
a  deeper  understanding  of  the  mission.  As  noted  earlier,  when  the  numbers  do  not 
properly  reflect  the  objective  of  the  mission,  the  commander  must  then  determine  if  the 
cargo  or  passengers  selected  is  accurate,  if  the  cargo  type  is  accurately  selected  in  the 
database,  or  if  there  is  another  reason  for  the  disconnection  between  the  data  and  the 
mission.  The  end-user  can  revert  back  to  TCPT  in  order  to  get  more  detailed  information 
on  certain  missions  to  provide  a  clearer  analysis. 

4.  Combo  Page 

The  Combo  page  combines  information  from  both  the  air  and  ground  platforms  to 
provide  a  combined  view  of  both  types  of  mission  information.  Figure  22  is  the  Combo 
page.  The  end-user  will  choose  a  unit  by  using  the  navigation  buttons.  The  unit  selected 
provides  information  for  missions  conducted  by  all  subordinate  units.  In  this  example,  the 
24th  MEU  was  selected  and  all  missions  conducted  by  their  subordinate  air  and  ground 
units  are  displayed. 
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Figure  22.  Transportation  Capacity  Tool  Application  Combo  Page. 


This  page  includes  the  unit,  mission  date,  mission  numbers  and  the  usage  rate  for 
each  mission.  Also  displayed  are  the  total  air  missions,  ground  missions  and  average 
usage  rates  for  each  platform.  This  information  is  valuable  to  a  commander  because  he  or 
she  can  see  how  each  platform  is  utilized  during  a  specific  timeframe.  To  get  a  more 
detailed  view  on  usage  rates,  the  end-user  can  select  the  “combo  totals”  button  to  see  a 
graphical  display  of  usage  rates.  Figure  23  is  the  totals  page. 
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Combo  I  Home 


Figure  23.  Transportation  Capacity  Tool  Application  Combo  Totals  Page 

The  “total  missions”  graph  depicts  the  air  and  ground  missions  conducted  by  the 
unit.  The  “ground  mission  usage”  graph  is  the  total  number  of  missions  that  fall  into  each 
usage  rate  category.  For  this  research,  the  researchers  depicted  red  as  0-60%  usage, 
yellow  as  61-80%  usage,  and  green  as  81-100%  usage.  The  “air  mission  usage”  graph 
depicts  the  total  number  of  missions  that  fall  into  each  usage  rate  category  as  well.  These 
graphs  give  the  commander  a  quick  synopsis  of  how  each  platform  is  performing  in  terms 
of  usage.  This  example  shows  that  on  both  the  air  and  ground  side,  the  majority  of 
missions  are  being  underutilized  at  below  60%.  As  mentioned  above,  some  missions  may 
need  further  interpretation  in  order  to  provide  an  accurate  evaluation. 

E.  FUTURE  ITERATIONS 

This  application  shows  a  commander,  in  one  place,  how  his  or  her  aviation  and 
ground  assets  are  being  utilized.  Logisticians  may  also  benefit  from  this  application  in 
determining  future  support.  This  application  was  built  as  a  proof  of  principle  to 
demonstrate  how  integrating  data  from  multiple  databases  into  one  dashboard  can 
provide  a  well-rounded  and  more  complete  view  of  a  unit’s  assets.  In  developing  this 
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application,  the  researchers  did  not  add  in  any  additional  functionality  or  cosmetic 
features  but  provide  recommendations  on  improvements  for  future  iterations. 

First,  a  more  user-friendly  search  tool  to  select  the  unit  and  date  could  be  added  to 
reduce  search  time.  Also,  different  graphics  could  be  used  to  represent  the  analytics  that 
are  more  appealing  to  those  briefing  commanders.  Lastly,  more  information  can  be  pulled 
from  TCPT  and  TBMCS  to  represent  other  aspects  of  transportation  capacity.  More 
specifically,  a  feature  could  be  added  to  show  how  many  assets  (air  or  ground)  were 
available  on  a  particular  day  and  how  many  were  being  used  for  missions.  The  end-user 
would  not  only  see  the  capacity  of  each  asset  used,  but  also  the  total  capacity  of  their  fleet 
being  used.  An  end-user  could  then  easily  calculate  a  ratio  and  develop  trends  lines  to 
identify  potential  improvements  in  efficiencies. 
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VI.  CONCLUSION 


This  chapter  summarizes  the  author’s  research  including  an  analysis  of 
organizational  design  and  Log  IT  systems  using  a  systems  approach  exemplified  by  a 
proof  of  principle  model.  Second,  the  researchers  answer  the  primary  research  questions 
posed  in  Chapter  I  from  the  methodology  used  for  this  thesis.  Third,  there  are  several 
lessons  learned  through  the  course  of  this  research  that  will  benefit  future  development  of 
transportation  analytics  at  the  tactical  level  of  operations  and  successive  Log  IT  system 
requirements.  This  chapter  also  includes  recommendations  based  on  the  lessons  learned. 
Lastly,  this  chapter  recommends  future  research  opportunities  for  the  Marine  Corps. 

This  chapter  is  organized  in  four  separate  sections:  Section  A  summarizes  this 
thesis,  Section  B  answers  the  primary  research  questions,  Section  C  covers  lessons 
learned  and  recommendations,  and  Section  D  proposes  future  research  opportunities. 

A.  SUMMARY 

This  thesis  explored  the  validity  of  applying  a  systems  approach  to  the  MAGTF  in 
order  to  increase  Marine  logistician’s  decision-making  and  meet  the  principles  set  forth  in 
EF21.  These  principles  include:  1)  support  an  expeditionary  mindset  and  2)  maximize 
organic  capabilities/limit  contracting  (HQMC,  2014a,  p.  41).  Guided  by  these  principles, 
the  researchers  accomplished  an  in  depth  review  and  discovered  that  not  only  were  Log 
IT  systems  critical  in  facilitating  these  goals,  but  the  management  and  use  of  these 
systems  was  also  essential  in  providing  MAGTF  commanders  the  necessary  information 
for  increased  situational  awareness  and  enhanced  decision  making. 

The  researchers  discovered  that  it  is  imperative  that  the  appropriate  organizational 
design  is  applied  to  the  three  different  levels  of  the  Marine  Corps  because  it  directly 
influences  how  successful  each  level  will  be  at  implementing  and  executing  policy.  At 
the  strategic  and  operational  level,  logistics  modernization  policies  need  to  be 
standardized  in  accordance  with  a  mechanistic  design  using  a  centralized  approach.  This 
standardization  will  increase  the  vertical  information  flow  throughout  the  Marine  Corps, 
which  is  enhanced  by  properly  using  Fog  IT  systems  to  support  strategic  goals.  At  the 
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tactical  level,  units  are  executing  the  strategic  goals  and  providing  feedback  in 
accordance  with  an  organic  design  using  a  decentralized  approach.  Horizontal 
communication  is  enhanced  across  the  MAGTF  when  the  Log  IT  systems  are  established 
to  support  communication  and  control  for  the  MAGTF  CE,  LCE,  ACE  and  GCE. 

For  instance,  the  researchers  discovered  that  loose  guidance  and  direction 
concerning  Log  IT  policy  documents  at  the  strategic  level  give  units  at  the  tactical  level 
the  ability  to  create  their  own  operating  procedures  and  choose  which  Log  IT  system  they 
want  to  employ  to  track  logistics.  While  commander’s  discretion  is  encouraged  at  the 
tactical  level,  it  should  not  apply  to  Log  IT  systems.  Instead,  commander’s  discretion 
should  be  used  to  influence  the  information  requirements  generated  by  the  Log  IT 
system.  Unfortunately,  current  practices  in  using  Log  IT  systems  impede  vertical  and 
horizontal  information  flow  because  each  unit  has  the  ability  to  dictate  which  Log  IT 
systems  they  want  to  use  and  there  is  a  copious  amount  of  options  available.  This  practice 
creates  a  gap  in  logistics  performance  metrics  across  the  Marine  Corps. 

The  researchers  applied  an  organic  design  model  to  the  MAGTF  and  discovered 
that  using  this  model,  horizontal  information  flow  between  the  LCE,  GCE  and  ACE 
could  be  increased  in  support  of  logistics  operations.  Increasing  both  vertical  and 
horizontal  information  flow  with  accurate  information  directly  correlates  into  increased 
efficiency  and  effectiveness.  This  thesis  demonstrated  the  validity  of  applying  the  organic 
design  model  to  the  MAGTF  by  specifically  addressing  both  air  and  ground 
transportation  assets  at  the  MEU. 

The  researchers  created  a  proof  of  principle  model  in  order  to  demonstrate  how 
well  a  MEU  commander’s  situational  awareness  could  be  improved  with  a  soundly 
designed  application.  For  this  thesis,  the  proof  of  principle  model  was  a  transportation 
dashboard  that  pulled  information  from  IT  systems  already  in  use  by  the  ACE  and  LCE 
in  order  to  show  that  the  MAGTF  CE  could  consolidate  this  information  and  make  better 
recommendations  and  analysis  on  how  effectively  the  MAGTF  employs  transportation 
assets  in  support  of  operations.  The  researchers  envision  that  the  MAGTF  CE  S-4  would 
benefit  most  from  using  this  transportation  dashboard  as  he  or  she  is  the  senior  logistician 
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within  the  MAGTF  CE  with  the  ability  to  impact  logistics  operations  throughout  the 
MEU. 

B.  RESEARCH  QUESTIONS 

1.  What  is  the  current  organization  of  the  MAGTF  as  it  relates  to  Log  IT 
systems  to  include  for  example,  roles,  users,  and  functionality? 

For  this  particular  thesis,  we  limited  the  question  to  only  address  the  Marine 
Expeditionary  Unit  (MEU)  using  IT  systems  for  both  air  and  ground  transportation.  The 
researchers  discovered  that  there  is  no  standard  for  units  to  use  Log  IT  systems,  which 
created  a  gap  in  the  MAGTF  commander’s  situational  awareness.  For  instance,  according 
to  current  policy,  units  could  use  either  TCPT  or  CLC2S  with  GCSS-MC  for  requesting 
and  tracking  ground  transportation.  For  air  transportation,  the  ACE  uses  TBMCS. 
Consolidating  relevant  logistics  information,  the  researchers  recommend  that  the 
MAGTF  CE  S-4  is  the  most  appropriate  agent  to  interpret  transportation  analytics  and 
provide  recommendations  to  the  MAGTF  commander  for  more  efficiently  and  effectively 
using  transportation  assets. 

2.  How  well  can  this  application  design  use  and  access  existing  logistics 
databases? 

In  using  Oracle  products,  there  will  be  limited  issues  when  accessing  existing 
databases.  Once  the  tables  are  loaded  into  the  application  using  SQL  scripts  through  SQL 
Developer,  the  application  can  easily  be  updated  with  current  data.  As  stated  previously, 
there  were  only  minor  modifications  made  to  the  structure  of  the  data  and  those  were 
done  within  the  model  layer  of  the  application.  Therefore,  updated  data  extracted  from 
TCPT  or  TBMCS  will  not  need  to  be  structurally  modified  before  importing  it  into  the 
application.  The  major  obstacle  foreseen  is  that  when  deployed,  both  databases  are 
located  on  a  secure  network.  The  application  must  be  built  on  a  secure  network  in  order 
to  maintain  the  integrity  of  the  data’s  classification.  Further  research  should  be  conducted 
to  determine  the  appropriate  frequency  in  which  data  should  be  extracted  and  loaded  into 
the  application  in  order  to  ensure  it  is  timely  and  useful  to  the  commander.  An  additional 
consideration  is  that  the  closer  the  data  is  to  near  real  time,  the  extraction  process  will  be 
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more  expensive.  Therefore,  a  cost-benefit  analysis  should  be  conducted  to  determine 
what  is  appropriate  and  effective  for  this  application. 

3.  Through  analytics,  how  can  we  use  information  from  command  and 

control  (C2)  and  in-transit  visibility  (ITV)  databases  to  effectively  employ 
air  and  ground  distribution  of  supplies  to  support  the  MAGTF? 

The  researchers  built  a  proof  of  principle  transportation  dashboard  that  could  be 
used  by  MAGTF  commanders  to  enhance  decision  making  by  automating  usage  metrics. 
For  example,  the  transportation  dashboard  provided  analytics  that  show  the  usage  rate  for 
each  mission  as  well  as  each  asset  on  that  mission.  For  aviation,  the  usage  rate  was 
determined  by  weight  and  passenger  restrictions  for  each  aircraft  type.  For  ground 
transportation,  it  was  determined  by  space,  weight  and  passenger  restrictions.  These 
metrics  depict  how  efficiently  and  effectively  units  are  employing  their  assets  for 
logistical  support  missions.  The  application  provides  information  related  to  each  mission 
as  well  as  combines  both  air  and  ground  onto  a  single  page.  No  other  system  in  the 
Marine  Corps  inventory  does  this.  A  commander  can  make  better  decisions  on  how  to  use 
his  or  her  assets  for  logistical  missions  by  combining  air  and  ground  usage  into  one  page. 

C.  LESSONS  LEARNED  AND  RECOMMENDATIONS 

This  section  summarizes  the  lessons  learned  during  this  thesis  development  that 
will  benefit  future  researchers  in  this  area.  This  section  also  provides  recommendations 
based  on  observations  throughout  the  course  of  this  study. 

Lessons  learned  are: 

•  Veracity  of  data  is  an  issue  and  negatively  impacted  the  quality  of  the 
transportation  analytics  the  researchers  performed. 

•  Bandwidth  directly  affects  how  effectively  Marine  logisticians  are  able  to 
use  IT  systems  in  a  deployed  environment. 

•  Policy  documents  that  are  not  standardized  and  enforced  through  formal 
reports  will  decrease  the  likelihood  that  they  are  successfully  implemented 
across  the  organization. 

•  Multiple  Log  IT  systems  are  not  effective  in  capturing  the  appropriate 
information  requirements  needed  for  a  MAGTF  commander  to  make  the 
most  informed  decision. 


66 


•  The  lack  of  feedback  mechanisms  within  the  MAGTF  will  perpetuate 
recurring  issues,  retard  implementation  of  policies  and  decrease  learning 
in  the  organization.  For  instance,  if  the  Marine  Corps  uses  a  feedback 
mechanism  supported  by  Log  IT  systems  then  strategic  goals  can  be  better 
assessed.  Once  positive  change  occurs  at  the  tactical  level,  the  Marine 
Corps  can  successfully  implement  these  changes  through  the  strategic  and 
operational  levels  in  a  centralized  fashion,  which  in  turn  promotes  learning 
and  improvement  supported  by  Log  IT  systems. 

Recommendations  are: 

•  Enforce  quality  of  data  entry  by  creating  drop  down  boxes  for  Log  IT 
systems  vice  allowing  Marines  to  type  entries.  Some  Log  IT  systems  give 
users  the  capability  to  type  entries,  which  increases  human  error  and 
reduces  the  accuracy  of  reports  generated  by  the  Log  IT  system. 

•  Capture  the  current  logistics  operational  architecture  from  MCBUL  4081 
using  a  systematic  approach  and  create  phased  plan  to  reduce  the  amount 
of  systems  Marine  logisticians  use  to  support  operations. 

•  Reduce  amount  of  Log  IT  systems  and  focus  funding.  The  logistics 
operational  architecture  will  be  improved  and  easier  to  maintain  by 
reducing  the  amount  of  Log  IT  systems.  Also,  the  Marine  Corps  can  use 
funds  saved  from  reducing  multiple  systems  to  further  develop  GCSS-MC 
into  a  better  tool  for  Marine  logisticians. 

•  GCSS-MC  is  an  enterprise  system  and  needs  to  be  the  backbone  of  the 
logistics  operational  architecture.  Based  on  GCSS-MC,  future  Log  IT 
systems  need  to  be  Oracle  based  and  have  the  ability  to  interact  with  the 
system.  Also,  facilitate  operational  security  by  migrating  GCSS-MC  to 
operate  on  SIPR  while  deployed. 

•  Facilitate  Joint  Log  IT  systems.  The  benefit  of  using  GCSS-MC  is  that  not 
only  is  it  an  enterprise  system,  but  it  also  can  be  used  in  conjunction  with 
GCSS-Army.  This  is  essential  in  joint  logistics  environments  for  support 
and  needs  to  be  a  metric  for  funding  future  Log  IT  systems. 

•  Improve  deployed  support  and  training.  Marines  are  deterred  from  using 
Log  IT  systems  while  deployed  when  the  Log  IT  system  does  not  work 
either  due  to  bandwidth  or  compatibility  issues  beyond  the  users  training 
or  experience.  Successfully  supporting  GCSS-MC  in  a  deployed 
environment  is  contingent  on  deployed  support  team  and  amount  of 
bandwidth  reserved  for  the  system. 

•  Automate  Log  IT  Systems.  Reduce  human  error  by  automating  the 
information  captured  by  Log  IT  systems.  This  type  of  Log  IT  system  will 
support  both  anticipatory  and  responsive  or  hybrid  method  of  support  to 
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provide  Marine  logisticians  greater  flexibility  with  more  accurate 
information. 

•  Create  a  logistics  command  and  control  (C2)  operational  advisory  group 
(OAG)  with  the  mandate  of  accomplishing  the  following  tasks:  1)  Develop 
strategic  goals,  2)  Develop  formal  reports  generated  by  the  Log  IT  system 
that  will  be  used  to  support  strategic  goals,  3)  Establish  metrics  of 
performance/effectiveness  and  4)  Develop  standardized  processes  on  how 
the  Log  IT  system  should  be  used  within  the  organization,  5)  Formalize 
positive  change  through  updated  policies. 

•  Designate  specific  military  occupational  specialists  (MOS)  to  use  Log  IT 
Systems.  For  instance,  within  the  MAGTF  CE  S-4,  an  MOS  0491 
Logistics/Mobility  Chief  is  most  appropriate  because  they  work  in 
collaboration  with  the  MAGTF  CE  S-4  Officer  and  are  trained  to  plan, 
coordinate  and  supervise  a  variety  of  logistical  functions  in  support  of 
operations.  Furthermore,  these  Marines  provide  valuable  first  hand 
expertise  on  improving  information  requirements  generated  by  the  Log  IT 
system  because  they  typically  come  from  either  the  MOS  0431 
Logistics/Embarkation  Specialists  or  MOS  0481  Landing  Support 
Specialists. 

•  Improve  formalized  training  to  increase  better  decision  making  and 
standardize  logistics  operations  across  the  MAGTF.  MOS  0491 
Logistics/Mobility  Chief  could  be  sent  to  formal  schools  as  provided  by 
the  Army  Logistics  University  (ALU)  or  the  Marine  Corps  Combat 
Service  Support  School  (MCCSSS)  to  encourage  building  personal 
relationships  across  the  community  and  serve  as  a  venue  to  update  policies 
in  a  school  environment  as  well  as  increase  learning  from  shared 
experience. 

•  Adopt  standard  business  processes  and  encourage  learning  across  the 
organization.  One  issue  with  supporting  multiple  Log  IT  systems  that 
provide  redundant  capabilities  is  that  it  creates  an  environment  where  each 
MEF  is  allowed  to  employ  Log  IT  systems  according  to  their  unique 
preferences  of  doing  business.  For  instance,  each  MEF  has  their  own 
unique  operating  procedures  that  dictate  which  Log  IT  systems  are  used  in 
support  of  operations.  Unfortunately,  each  MEF  operates  differently  and 
may  prefer  one  Log  IT  system  over  another  which  trickles  into  the  tactical 
units.  As  a  result,  individual  Marines  moving  from  I  MEF  to  II  MEF  or  III 
MEF  will  be  required  to  leam  different  methods  of  accomplishing  similar 
tasks.  This  practice  decreases  efficiency  and  effectiveness,  as  individual 
Marines  will  need  time  to  adapt  to  new  environments.  By  standardizing 
Log  IT  systems  across  the  organization,  Marines  will  more  easily  adapt  to 
new  environments  and  will  more  effectively  accomplish  tasks  while 
supporting  complex,  dynamic  operations. 
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•  Enforce  the  appropriate  level  of  expertise  is  using  the  application  and 
interpreting  the  results.  While  having  a  Log  IT  system  generate  a 
formalized  report  is  convenient  for  the  commander,  it  may  not  be 
beneficial  if  the  end  user  does  not  understand  the  data  contained  within  the 
reports.  For  example,  hazardous  materials  may  restrict  an  aircraft’s  ability 
to  maximize  its  cargo  utilization.  This  low  utilization  metric  should  not 
adversely  impact  the  aircraft.  It  is  imperative  that  the  appropriate  level  of 
expertise  provide  the  commander  with  this  kind  of  granularity  when 
briefing  metrics  that  are  indicative  of  performance. 

•  Recognize  and  implement  current  data  trends.  As  the  Marine  Corps 
collects  more  logistical  data,  the  organization  should  leverage  this  data 
and  apply  the  principles  of  big  data  analytics  while  also  balancing  the 
related  challenges  of  big  data  such  as  volume,  variety,  veracity,  and 
velocity  in  order  to  provide  the  best  analytics  and  metrics  on  their 
performance.  Applying  these  principles  will  give  Marine  logisticians  the 
granularity  to  make  the  most  informed  decision  when  making  a 
recommendation  to  the  MAGTF  commander  on  how  to  use  his  or  her 
transportation  assets. 

•  Replacing  obsolete  and  outdated  systems.  As  the  Marine  Corps  funds  new 
IT  systems  or  removes  IT  systems  from  their  inventory,  the  application 
developed  in  this  thesis  can  still  be  applied  with  minimal  changes.  The 
Model-View-Controller  framework  implemented  by  ADF  allows  for  the 
data-model  to  be  updated  without  needing  to  rebuild  the  view  and 
controller  layer.  The  metrics  may  change  based  on  the  data  provided  by 
the  new  IT  system,  but  the  overall  function  of  the  application  will  remain. 
Also,  new  analytics  from  the  same  data  sources  can  be  developed  rapidly 
to  meet  new  tactical  challenges.  This  feature  would  be  extremely  useful  in 
the  case  of  either  TCPT  or  TBMCS  becoming  obsolete. 


D.  FUTURE  AREAS  OF  RESEARCH 

Currently,  the  DOD  employs  contractors  to  build,  maintain,  and  work  databases 
and  applications  that  are  used  to  support  decision-making  within  the  logistics  and  supply 
fields.  These  projects  typically  have  ill-defined  requirements  resulting  in  projects  that  are 
over  budget  and  behind  schedule  because  of  the  lack  of  DOD  expertise  in  these  unique 
fields.  In  order  to  be  more  efficient  and  build  a  better  application  to  meet  user 
requirements,  the  DOD  could  train  individuals  in  rapid  application  development  using 
Oracle -based  software.  DOD  trained  users  could  develop  these  applications  to  meet 
specific  needs  of  a  commander  or  a  unique  mission  set.  Additionally,  these  applications 
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could  pull  information  from  current  deployed  databases  in  order  to  provide  useful 
analytics  and  reports.  The  ability  to  rapidly  develop  and  modify  an  application  without 
being  restricted  by  a  contract  is  extremely  beneficial  because  the  DOD  operates  in  a 
dynamic  environment.  A  potential  future  project  could  be  to  conduct  a  cost-benefit 
analysis  on  using  contractors  to  develop  applications  versus  sending  individuals  through 
Oracle -based  training  to  develop  their  own  applications.  A  mock  application  could  be 
built  as  a  proof-of-concept  to  support  the  idea  of  using  internal  personnel  to  build 
applications  that  meet  the  unique  mission  requirements  that  are  set  by  the  MAGTF 
commander. 
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APPENDIX  A.  DEPLOYED  MDDOC  STRUCTURE  TEMPLATE 


MCO  4470. 1A 
03  NOV  2014 


DEPLOYED  MDDOC  STRUCTURE  TEMPLATE 


FIGURE  2.— MDDOC  STRUCTURE  -  DEPLOYED 


(Recommended  structure,  only.  Actual  structure  is  at  the  discretion  of  the 
MEF  Commander.) 


Figure  24.  Deployed  MDDOC  Structure.  Source:  Department  Of  Navy  (2014). 
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APPENDIX  B. 


This  appendix  lists  the  schemas,  tables  and  attributes  from  both  TCPT  and 
TBMCS  that  are  used  to  build  the  view  objects.  This  list  would  be  used  in  the  extraction, 
transform  and  load  (ETL)  process. 

A.  TCPT  DATABASE 
1.  TCPT  Schema 

a.  Table:  Units 

•  Attributes: 

ID 

Name 

Short_Name 
Parent_ID 
Locational  D 

b.  Table:  Mission 

•  Attributes: 

ID 

Organization_ID 
Arrival_Time 
Destination 
Mi  s  sion_Di  stance 

c.  Table:  MasterLog 

•  Attributes: 

Master_ID 

MissionJD 

Equipment_ID 

Fuel_Used 

Load_ID 

Miles_Traveled 

Passengers 

Cargo_Weight 
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d.  Table:  Load 

•  Attributes: 

Load_ID 

Mission_ID 

e.  Table:  LoadEquipment 

•  Attributes: 

Equipment_ID 

Load_ID 

/.  Table:  LoadTMRLines 

•  Attributes: 

Load_ID 

TMR_Line_Item_ID 

Qty 

g.  Table:  TMR_Lines_Items 

•  Attributes: 

ID 

Cargo_ID 

h.  Table:  Cargo _P ax _Type 

•  Attributes: 

ID 

Description 

i.  Table:  Equipment  jCapabilities 

•  Attributes: 

Equipment_ID 

FOURSIXTHREELON 

FUELON 

ISOON 

PALCON_ON 

PAXON 

QUADCONON 

SIXCONON 
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STDPALLETON 

TEU_ON 

TOTALSTON 

WATERBULKON 

j.  Table:  Equipment 

•  Attributes: 

Equipment_ID 

TAMCN_ID 

k.  Table:  TAMCNS 

•  Attributes: 

ID 

NOMENCLATURE 

B.  TBMCS  DATABASE 

l.  ATOPLN  Schema 

a.  Table:  MSN 

•  Attributes: 

Tasked_FR_UNIT_ID 

MSN_WW_ID 

ABP_WW_ID 

b.  Table:  Abp_Req 

•  Attributes: 

AB  P_REQ_NLT_DTTM 
ABP_WW_ID 
ABP_REQ_ID 
MS  N_C  AT_CD 

c.  Table:  ASR_MSN_PRG 

•  Attributes: 

ASR_REQ_ID 

ABP_WW_ID 

ABP_REQ_ID 

MSN_WW_ID 
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ASR_MSN_PRG_ID 

AMO_ID 

Table:  Air_MSN 

Attributes: 

Air_MSN_T  akeoff_Loc_NM 

MSN_WW_ID 

Air_MSN_Landing_Loc_NM 

Table:  Air_MSN_A  CFT 

Attributes: 

ACFT_MDS_TYPE_CD 

MSN_WW_ID 

Air_MSN_ACFT_Group_ID 

Air_MSN_ACFT_Aircraft_QTY 

Table:  ASR 

Attributes: 

ASR_PYFD_EXTR_Cargo_WT 

ABP_WW_ID 

ABP_REQ_ID 

ASR_REQ_ID 

ASR_PYFD_INT_Cargo_WT 
ASR_PYFD_Troop_TX 
ASR_PYFD_T  ype_CD 


FROBDB  Schema 
Table:  FRUnit 
Attributes: 

Unit_ID 

Unit_CTRY_CD 
Unit_Parent_ID 
Unit_Parent_CTRY_CD 
FOC  NM 


3. 


TMBSUP  Schema 


a.  Table:  Aircraft _Details 

•  Attributes: 

Aircraft_Model_C  ode 
Cargo_Capacity 
Passenger_Capacity 
SCL 
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APPENDIX  C 


This  appendix  provides  the  SQL  scripts  used  to  build  the  View  Objects  for  each 
page  within  the  application;  the  transient  attributes  that  were  developed;  the  view  links 
that  connect  each  view  object;  and  the  data  model  for  each  application  module. 


A.  AIR  PAGE 

1.  View  Objects: 
a.  Air_Unit_InfoVO 

SELECT  FrUnit_EO . FR_UNIT_ID,  FrUnit_EO . FR_UN I T_CTR Y_CD , 
FrUnit_EO  .  FR_UNIT_PARENT_ID ,  FrUnit_EO  .  FR_UN I T_P ARENT_CTR Y_CD 
,  FrUnit_EO . LOC_NM  FROM  COMBINED_SCHEMA . FROBDB_FR_UNIT 
FrUnit_EO  WHERE  Frunit_EO . Fr_Unit_ID  =  ' 24MEU ' )  OR 
(Frunit_EO . Fr_Unit_ID  =  ' 11MEU')  OR  ( Frunit_EO . Fr_Unit_ID  = 
'24  MEU  CE')  OR  ( Frunit_EO . Fr_Unit_ID  =  '11  MEU  CE 1 )  OR 
(Frunit_EO . Fr_Unit_ID  =  'VMM163')  OR  ( Frunit_EO . Fr_Unit_ID  = 
' VMM 3 65') 


This  view  object  has  a  ‘where’  clause  so  that  it  will  only  pull  data  for  the  units 
that  fall  under  the  24th  and  11th  MEUs.  This  allows  the  user  to  customize  the  data  that 
they  will  be  viewing. 


b. 


Air  Unit  DateVO 


SELECT  Msn_EO . TASKED_FR_UNIT_ID ,  Msn_EO . MSN_WW_ID , 
AbpReq_EO . ABP_REQ_NLT_DTTM ,  AbpReq_EO . ABP_WW_ID , 
AbpReq_EO . ABP_REQ_ID  FROM  COMBINED_SCHEMA . ATOPLN_MSN 
Msn_EO ,  COMBINED_SCHEMA . ATOPLN_ABP_REQ  AbpReq_EO  WHERE 
(Msn_EO.MSN_WW_ID  =  AbpReq_EO . MSN_WW_ID)  AND 
( (Msn_EO . TASKED_FR_UNIT_ID  =  ' 24MEU ' )  OR 
(Msn  EO. TASKED  FR  UNIT  ID  = 


(Msn_EO . TASKED_FR_UNIT_ID  = 
(Msn_EO . TASKED_FR_UNIT_ID  = 
(Msn_EO . TASKED_FR_UNIT_ID  - 
(Msn_EO . TASKED_FR_UNIT_ID  = 
AbpReq_EO . ABP_REQ_NLT_DTTM 


1 1MEU ' )  OR 
24  MEU  CE ' )  OR 
11  MEU  CE ' )  OR 
VMM163 ' )  OR 
VMM365 ' ) )  ORDER  BY 
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This  view  object  has  a  ‘where’  clause  so  that  it  will  only  pull  data  for  the  units 
that  fall  under  the  24th  and  11th  MEUs.  This  allows  the  user  to  customize  the  data  that 
they  will  be  viewing. 

c.  Air_MissionVO 

SELECT  Msn_EO . TAS KED_FR_UN I T_ I D ,  Msn_EO . MSN_WW_ID , 

Msn_EO . ABP_WW_ID ,  AsrMsnPrg_EO . ASR_REQ_ID , 

AsrMsnPrg_EO . ABP_WW_ID  AS  ABP_WW_ID1, 

AsrMsnPrg_EO . ABP_REQ_ID,  AsrMsnPrg_EO . MSN_WW_ID  AS 
MSN_WW_ID1 ,  AsrMsnPrg_EO . ASR_MSN_PRG_ID , 

AsrMsnPrg_EO . AMO_ID,  AbpReq_EO . ABP_REQ_NLT_DTTM, 

AbpReq_EO . ABP_WW_ID  AS  ABP_WW_ID2 ,  AbpReq_EO . ABP_REQ_ID  AS 
ABP_REQ_ID1 ,  AbpReq_EO . MSN_CAT_CD  FROM 
COMBINED_SCHEMA . ATOPLN_MSN 

Msn_EO , COMBINED_SCHEMA . ATOPLN_ASR_MSN_PRG 

AsrMsnPrg_EO , COMBINED_SCHEMA . ATOPLN_ABP_REQ  AbpReq_EO  WHERE 
(Msn_EO . MSN_WW_ID  =  AsrMsnPrg_EO . MSN_WW_ID)  AND 
(Msn_EO.MSN_WW_ID  =  AbpReq_EO . MSN_WW_ID)  AND 
( (Msn_EO . TASKED_FR_UNIT_ID  =  ' 24MEU ' )  OR 
(Msn_EO . TASKED_FR_UNIT_ID  =  '11MEU')  OR 
(Msn_EO . TASKED_FR_UNIT_ID  =  '24  MEU  CE ' )  OR 
(Msn_EO . TASKED_FR_UNIT_ID  =  'll  MEU  CE ' )  OR 
(Msn_EO . TASKED_FR_UNIT_ID  =  'VMM163')  OR 
(Msn_EO . TAS  KED_FR_UN I T_ I D  =  ' VMM3  6  5 ' )  ) 

•  Transient  Attributes 

1.  Total  Usage 

Type:  Number 
UI  Hint/Format  Type:  None 

Groovy  Expression:  Air_Mission_DetailsVO.("Total_Usage")*100 

2.  Total  Usage  Percent 

Type:  Number 

UI  Hint/Format  Type:  Percentage 

Groovy  Expression:  Air_Mission_DetailsVO.("Total_Usage") 

This  view  object  has  a  ‘where’  clause  so  that  it  will  only  pull  data  for  the  units 
that  fall  under  the  24th  and  11th  MEUs.  This  allows  the  user  to  customize  the  data  that 
they  will  be  viewing. 
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d.  Air  Mission  De tails  VO 


SELECT  Asr_EO . ASR_UNIT_CALLED_NM , 

AsrMsnPrg_EO . ASR_MSN_PRG_ID , 

AsrMsnPrg_EO . ABP_WW_ID,  AsrMsnPrg_EO . ABP_REQ_ID, 
AsrMsnPrg_EO . ASR_REQ_ID,  AsrMsnPrg_EO . MSN_WW_ID, 
AsrMsnPrg_EO . AMO_ID ,  AirMsn_EO . AIR_MSN_TAKEOFF_LOC_NM, 
AirMsn_EO.MSN_WW_ID  AS  MSN_WW_ID1, 

A i r M s n_E O . A I R_M S N_L AND I N G_LO C_NM , 

Ai rMsnAc  f  t_EO . ACFT_MDS_TYPE_CD ,  AirMsnAcf t_EO . MSN_WW_ID  AS 
MSN_WW_ID2 ,  AirMsnAcf t_EO . AIR_MSN_ACFT_GROUP_ID , 

Ai rMsnAc f t_EO . AI R_MSN_ACFT_AI RCRAFT_QY , 

Asr_EO . ASR_PYLD_EXTR_CARGO_WT ,  Asr_EO . ABP_WW_ID  AS 
ABP_WW_ID1 ,  Asr_EO . ABP_REQ_ID  AS  ABP_REQ_ID1 , 

Asr_EO . ASR_REQ_ID  AS  ASR_REQ_ID1 , 

Asr_EO . AS R_P YLD_ I NT_CARGO_WT ,  TO_NUMBER 
(Asr_EO . ASR_PYLD_TROOP_TX) * ,  Asr_EO . ASR_PYLD_TYPE_CD , 
Aircraf tDetails_EO . AIRCRAFT_MODEL_CODE , 

Aircraf tDetails_EO . CARGO_CAPACITY, 

Aircraf tDetails_EO . PAS  S  ENGER_CAPAC I T Y , 

Aircraf tDetails_EO . SCL  FROM 

COMBINED_SCHEMA . ATOPLN_ASR_MSN_PRG  AsrMsnPrg_EO , 
COMBINED_SCHEMA . ATOPLN_AIR_MSN  AirMsn_EO , 

COMBINED_SCHEMA . ATOPLN_AIR_MSN_ACFT 
Ai rMsnAc  f  t_EO , COMB INED_SCHEMA . ATOPLN_ASR 

Asr_EO , COMBINED_SCHEMA . AIRCRAFT_DETAILS  Aircraf tDetails_EO 
WHERE  (AsrMsnPrg_EO . MSN_WW_ID  =  AirMsn_EO . MSN_WW_ID)  AND 
(AirMsn_EO . MSN_WW_ID  =  AirMsnAcf t_EO . MSN_WW_ID)  AND 
(AsrMsnPrg_EO . ASR_REQ_ID  =  Asr_EO . ASR_REQ_ID)  AND 
(AirMsnAcf t_EO . Acf t_MDS_TYPE_CD  = 

Aircraf tDe tail s_EO . Aircraf t_Model_code)  AND 
(ASR_EO . ASR_Pyld_Type_CD  =  Aircraf tDetails_EO . SCL) 


•  Transient  Attributes 

1.  ASR_INT_PLYD 

Type:  Number 

UI  Hint/Format  Type:  Percentage 
Groovy  Expression: 

if(AsrPyldIntCargoWt>0)  { (AsrPyldlntCargoWt/CargoCapacity) } 
else  if(AsrPyldIntCargoWt  ==  0)  { 0 } 

2.  ASR_EXT_PLYD 

Type:  Number 

UI  Hint/Format  Type:  Percentage 
Groovy  Expression: 
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if(AsrPyldExtrCargoWt  >  0) 

{ (AsrPyldExtrCargoWt/CargoCapacity)  }else 
if(AsrPyldExtrCargoWt  ==  0)  { 0 } 


3.  ASR_PAX 

Type:  Number 

UI  Hint/Format  Type:  Percentage 

Groovy  Expression: 

if(AsrPyldTroopTx  >  0){(AsrPyldTroopTx/PassengerCapacity)} 

else  if(AsrPyldTroopTx  ==  0)  { 0 1 

4.  Total  Usage 

Type:  Number 

UI  Hint/Format  Type:  Percentage 

Groovy  Expression:  Asr_Int_Pyld  +  Asr_Ext_Pyld  +  Asr_Pax 

As  noted  by  the  in  the  ‘Air_Mission_DetailsVO,’  the  attribute 

‘ASR_PYLD_Troop_TX’  from  the  ASR  table  in  the  ATOPLN  schema  has  a 
‘To_Number’  command  before  it.  This  is  because  in  the  database,  this  field  is  a  text  field. 
In  order  to  do  the  necessary  calculations,  it  must  be  converted  into  a  number  field.  This 
will  not  cause  an  issue  with  the  ETL  process  because  this  manipulation  does  not  occur  at 
the  model  layer.  It  is  happening  in  the  control  layer  via  this  view  object  in  Figure  25. 
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^1  model  view 
AirJJnitJnfoVO 
Frllntld :  String 
FrUntCtryCd :  9ring 
FrUntParentld  String 
FrUntParentCtryCd :  String 
LocNn :  String 


model  view 
Air_MissionVO 
TaskedFrUnitld :  String 
MsnWwId :  String 
AbpWwId :  String 
AsrReqld :  String 
AbpWwIdl  :  String 
AbpReqld  String 
.MsnWwIdl  :  String 
AsrMsnPrgld :  String 
Arnold :  Integer 
AbpPeqNltDttm :  Timestamp 
AbpWwld2 :  String 
AbpReqldl  :  String 
MsnCatCd :  String 
TotalUsage :  Number 
TotalUsagePercent  Number 


Air  Unit  DateVL 


1  to  Many 


model  view 
Ajr_Unit_D£teVO 
TaskedFrUnitld  String 
MsnWwId :  String 
*  AbpReqNltDttm .  Timestamp 
AbpWwId  String 
AbpReqld  String 


AsrUnitCaledNm  String 
AsrMsnPrgld  String 
AbpWwId :  String 
AbpReqld .  String 
AsrReqld :  String 
MsnWwId :  String 
Arnold :  Integer 
AirMsnTakeoffLocNm :  String 
MsnWwIdl  String 
AirMsnLandingLocNm :  String 
AcftMdsTypeCd :  String 
MsnWwld2  String 
AirMsnAcftGroupId :  String 
AirMsnAcftAircraftQy  Integer 
AsrPyldExtrCargoVM :  BigDecimal 
AbpWwIdl  String 
AbpReqldl  String 
AsrReqldl  :  String 
AsrPyldlntCargoVW  BigDecimal 


This  shows  the  view  objects  and  view  links  used  to  build  the  air  page. 


Figure  25.  Air  Page  View  Object  and  View  Link  Relationship 


2.  View  Links 

a.  Air_Unit_InfoVO  to  Air_Unit_DateVO 

Source:  Air_Unit_InfoVO.FrUnitID 
Destination:  Air_Unit_DateVO.TaskedFrUnitId 
Cardinality:  1  to  many 

b.  AirJU n it_Date  VO  to  Air_Mission  VO 

Source :  Air_U nit_Date V O . T askedFrU nitld 
De  s  tination:  Air_Mi  ssion V  O .  T  askedFrU  nitld 
Source:  Air_U nit_Date V O . AB PREQNLTDTTM 
Destination:  Air_MissionVO. ABPREQNLTDTTM 
Cardinality:  1  to  many 

c.  Air_Mission_VO  to  Air_Mission_DetailsVO 
Source:  Air_MissionVO.MSNWWID 
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Destination:  Air_Mission_DetailsVO.MSNWWID 
Cardinality:  1  to  1 

3.  Application  Module 

The  air  application  module  is  to  be  built  as  shown  in  the  Figure  26. 


Data  Model: 

li 

0  |§]  Air_Unit_InfoV01 
&-JB  Air_Unit_DateVO  1 
6  £3  Air_MissionV01 

£r3  Air_Mission_DetailsV01 


Figure  26.  Air  Application  Module 


B.  GROUND  PAGE 

1.  View  Objects 
a.  Ground _U nit _InfoVO 

SELECT  TcptUnits_EO . ID,  TcptUni t s_EO . SHORT_NAME , 
TcptUnits_EO . PARENT_ID,  TcptUni ts_EO . LOCATION_ID  FROM 
COMBINED_SCHEMA . TCPT_UNITS  TcptUnits_EO  WHERE 
(TcptUni ts_EO . ID  =  3317)  OR  (TcptUni ts_EO . ID  =  1280) 
OR  (TcptUnits_EO . ID  =  532)  OR  (TcptUni ts_EO . ID  =  3) 
OR  (TcptUnits_EO . ID  =  554)  OR  (TcptUni ts_EO . ID  =  63) 


This  view  object  has  a  where  clause  so  that  it  will  only  pull  data  for  the  units  that 
fall  under  the  24th  and  11th  MEUs.  This  allows  the  user  to  customize  the  data  that  they 
will  be  viewing. 

b.  Ground JO nit _DateVO 

SELECT  TcptMission_EO . ID, 

TcptMission_EO . ORGAN I Z AT I ON_I D , 

TcptMission_EO . ARRIVAL_TIME  FROM 

COMBINED_SCHEMA . TCPT_MISSION  TcptMission_EO  ORDER  BY 
TcptMission_EO . ARRIVAL_TIME 
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c.  Ground _MissionVO 

SELECT  TcptMission_EO . ORGAN I Z AT I ON_I D , 
TcptMission_EO . ID,  TcptMission_EO . ARRIVAL_TIME , 
TcptMission_EO . DESTINATION, 

TcptMission_EO . MISSION_DISTANCE , 

TcptUnits_EO . ID  AS  ID1,  TcptUnits_EO . NAME  FROM 
COMBINED_SCHEMA . TCPT_MISSION  TcptMission_EO, 
COMBINED_SCHEMA . TCPT_UNITS  TcptUnits_EO  WHERE 
TcptMission_EO . ORGANIZATION_ID  =  TcptUni t s_EO . ID 


•  Transient  Attributes 

1.  Vehicle  Count 

Type:  Number 

UI  Hint/Format  Type:  Number 
Groovy  Expression: 

Ground_Mission_VehiclesVO.count("EquipmentId") 

2.  Total  Cargo 

Type:  Number 
UI  Hint/Format  Type:  None 
Groovy  Expression: 

Ground_Mission_VehiclesVO.sum("CargoWeight") 


3.  Total  Pax 

Type:  Number 

UI  Hint/Format  Type:  Number 
Groovy  Expression: 

Ground_Mission_V  ehicles  V  O .  sum(  "Pas  sengers ") 


4.  Mission  Space  Usage 
Type:  Number 

UI  Hint/Format  Type:  Percentage 
Groovy  Expression: 

if(VehicleCount  >0)  { Ground_Mission_VehiclesVO.avg 
("SpaeeCapaeity")}else{0} 


5.  Mission  Pax  Usage 

Type:  Number 

UI  Hint/Format  Type:  Percentage 
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Groovy  Expression: 

if(  V  ehicleCount>0)  { Ground_Mission_Vehicles  V  O  .avg(  "Pas  senge 
rCapacity " ) }  else  { 0 } 

6.  Mission  Weight  Usage 

Type:  Number 

UI  Hint/Format  Type:  Percentage 
Groovy  Expression: 

if(VehicleCount  >0)  { Ground_Mission_VehiclesVO.avg 
("  WeightCapacity ") }  else  { 0 } 

7.  Total  Usage 

Type:  Number 
UI  Hint/Format  Type:  None 

Groovy  Expression:  (MissionSpaceUsage  +  MissionPaxUsage  + 
MissionWeightUsage)*  100 

8.  Total  Usage  Percent 

Type:  Number 

UI  Hint/Format  Type:  Percentage 

Groovy  Expression:  (MissionSpaceUsage  +  MissionPaxUsage  + 
MissionWeightUsage) 


d.  Ground _Mission_  Vehicles  VO 

SELECT  TcptMasterLog_EO . MASTER_ID, 

TcptMasterLog_EO . MISSION_ID, 

TcptMasterLog_EO . EQUIPMENT_ID, 

TcptMas terLog_EO . FUEL_USED , 

TcptMasterLog_EO . LOAD_ID, 

TcptMas terLog_EO . MILES_TRAVELED , 

TcptMas terLog_EO . PASSENGERS , 

TcptMasterLog_EO . CARGO_WEIGHT , 

TcptLoad_EO . LOAD_ID  AS  LOAD_IDl,  TcptLoad_EO . MISSION_ID 
AS  MISSION_IDl , 

TcptLoadEquipment_EO . EQUIPMENT_ID  AS  EQUIPMENT_ID1 , 
TcptLoadEquipment_EO . LOAD_ID  AS  LOAD_ID2, 
TcptLoadTmrLines_EO . LOAD_ID  AS  LOAD_ID3, 
TcptLoadTmrLines_EO . TMR_LINE_ITEM_ID , 
TcptLoadTmrLines_EO . QTY,  TcptTmrLinei tems_EO . ID, 
TcptTmrLinei tems_EO . CARGOID ,  TcptCargoPaxType_EO . ID  AS 
ID1,  TcptCargoPaxType_EO. DESCRIPTION, 
TcptEquipmentCapabilities_EO . EQUIPMENT_ID  AS 
EQUIPMENT_ID2 , 
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TcptEquipmentCapabilities_EO . FOURS IXTHREELON, 
TcptEquipmentCapabilities_EO . FUELON, 
TcptEquipmentCapabilities_EO . ISOON, 
TcptEquipmentCapabilities_EO . PALCON_ON, 
TcptEquipmentCapabilities_EO . PAXON, 
TcptEquipmentCapabilities_EO . QUADCONON, 
TcptEquipmentCapabilities_EO . SIXCONON, 
TcptEquipmentCapabilities_EO . STDPALLETON, 
TcptEquipmentCapabilities_EO . TEU_ON, 
TcptEquipmentCapabilities_EO . TOTALSTON, 
TcptEquipmentCapabilities_EO . WATERBULKON, 
TcptEquipmentCapabilities_EO . WATERUNITON, 
TcptEquipment_EO . EQUIPMENT_ID  AS  EQUIPMENT_ID3 , 
TcptEquipment_EO . TAMCN_ID ,  TcptTamcns_EO . ID  AS  ID2 , 
TcptTamcns_EO . NOMENCLATURE  FROM 

COMBINED_SCHEMA . TCPT_MASTER_LOG  TcptMasterLog_EO , 
COMBINED_SCHEMA . TCPT_LOAD  TcptLoad_EO, 

COMBINED_SCHEMA . TCPT_LOAD_EQUIPMENT 
TcptLoadEquipment_EO , 

COMB I NED_S CHEMA . TCPT_LOAD_TMR_L I NE  S 

TcptLoadTmrLines_EO,  COMBINED_SCHEMA . TCPT_TMR_LINEITEMS 
TcptTmrLineitems_EO, 

COMBINED_SCHEMA . TCPT_CARGO_PAX_TYPE 
TcptCargoPaxType_EO , 

COMB INED_SCHEMA . TCPT_EQUI PMENT_CAPAB I L I T I ES 
Tcpt Equipment Capabilities_EO, 

COMB INED_SCHEMA . TCPT_EQUI PMENT  Tcpt Equipment_EO , 
COMBINED_SCHEMA . TCPT_TAMCNS  TcptTamcns_EO  WHERE 
( ( ( ( (TcptMasterLog_EO . Load_ID  =  TcptLoad_EO . Load_ID) 

AND  (TcptLoad_EO . LOAD_ID  = 

TcptLoadEquipment_EO . LOAD_ID) ) 

AND  (TcptMasterLog_EO . Equipment_ID  = 
TcptLoadEquipment_EO . Equipment_ID) 

AND  (TcptLoadEquipment_EO . LOAD_ID  = 

TcptLoadTmrLines_EO . LOAD_ID) ) 

AND  (TcptLoadTmrLines_EO . TMR_LINE_ITEM_ID  = 
TcptTmrLineitems_EO . ID) ) 

AND  (TcptTmrLineitems_EO . CARGOID  = 

TcptCargoPaxType_EO . ID) ) 

AND  (TcptLoadEquipment_EO . Equipment_ID  = 
TcptEquipmentCapabilities_EO . Equipment_ID) 

AND  (TcptLoadEquipment_EO . Equipment_ID  = 
TcptEquipment_EO . Equipment_ID) 

AND  (TcptEquipment_EO . TAMCN_ID  =  TcptTamcns_EO . ID) 


•  Transient  Attributes 

1.  Weight  Capacity 

Type:  Number 

UI  Hint/Format  Type:  Percentage 
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Groovy  Expression:  if(CargoWeight  >  0  &&  Totalston  > 

0)  { ((CargoWeight/2000)/T  otalston) }  else  { 0 } 

2.  Passenger  Capacity 

Type:  Number 

UI  Hint/Format  Type:  Percentage 

Groovy  Expression:  if(Passengers  >  0  &&  Paxon  > 

0)  { Pas  sengers/Paxon }  else  { 0 } 

3.  Space  Capacity 

Type:  Number 

UI  Hint/Format  Type:  Percentage 
Groovy  Expression:  if(Cargoid  ==  1  &&  Isoon  > 
0){Qty/Isoon}else  if(Cargoid  ==  2  &&  Stdpalleton  > 
0){Qty/Stdpalleton}else  if(Cargoid  ==  3  &&  Foursixthreelon  > 
0){Qty/Eoursixthreelon}else  if(Cargoid  ==  4  &&  Totalston  > 
0){Qty/Totalston}else  if(Cargoid  ==  5  &&  Quadconon  > 
0){Qty/Quadeonon}else  if(Cargoid  ==  6  &&  Fuelon  > 
0){Qty/Euelon}else  if(Cargoid  ==  7  &&  Waterbulkon 
>0){QtyAVaterbulkon}else  if(Cargoid  ==  8  &&  Wateruniton 
>0){Qty/Wateruniton}else  if(Cargoid  ==  9  &&  Paxon  > 
0){Qty/Paxon}else  if(Cargoid  ==  22  &&  TeuOn  > 
0){Qty/Teuon}else  if(Cargoid  ==  16){0}else{0} 


88 


£^|  model  view 

GroundJJnitJnfoVO 

G  round U  nit DateVL 

fci)  model  view 

Ground  _Unit_DateVO 

Id :  BigDecimal 

Id :  BigDecimal 

Organizations  BigDecimal 
ArrivalTime :  Timestamp 

Parentld :  BigDecimal 

Locations  BigDecimal 

1  to  Many 

model,  view 
Grourtd_MissionVO 
Organization^ :  BigDecimal 
Id :  BigDecimal 
ArrivalTime :  Timestamp 
Destination :  String 
MissionDistance ;  String 
Idl  :  BigDecimal 
Name  String 
VehicleCount :  Number 
TotalCargo :  Number 
TotalPax :  Number 
MissionSpaceUsage :  Numb 
MissionPaxllsage :  Number 
MissionWeightUsage :  Nunit 
TotalUsage :  Number 
TotalUsagePercent ;  Numbe 


£^)  model  view 

Ground_Mission_VehiclesVO 
Masterld :  BigDecimal 
Missionld  BigDecimal 
Equipments :  BigDecimal 
FuelUsed :  BigDecimal 
Loadld :  BigDecimal 
MilesTraveled  BigDecimal 
Passengers :  BigDecimal 
CargoWeight  BigDecimal 
’Loadldl  :  BigDecimal 
Missionldl  :  BigDecimal 
Equipments  BigDecimal 
Loadld2 :  BigDecimal 
Loadld3 :  BigDecimal 
TmrLineltemld :  BigDecimal 
Oty  BigDecimal 
Id :  BigDecimal 
Cargoid :  BigDecimal 
Idl  :  BigDecimal 


This  shows  the  view  objects  and  view  links  used  to  build  the  ground  page. 


Figure  27.  Ground  Page  View  Object  and  View  Link  Relationship 

2.  View  Links 

a.  Ground JU nit _InfoVO  to  Ground _U nit _DateVO 

Source:  Ground_Unit_InfoVO.Id 

Destination:  Ground_Unit_DateVO.OrganizationId 

Cardinality:  1  to  many 

b.  Ground _Unit_DateVO  to  Ground _MissionVO 

Source:  Ground_Unit_DateVO.Id 
Destination:  Ground_MissionVO.Id 
Cardinality:  1  to  many 

c.  Ground _MissionVO  to  Ground_Mission_VehiclesVO 

Source:  Ground_MissionVO.Id 

Destination:  Ground_Mission_VehiclesVO.MissionId 

Cardinality:  1  to  many 

3.  Application  Module 

The  ground  application  module  should  be  built  as  shown  in  Figure  28. 
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Ground 


S  jS  Ground_Unit_InfbVO  1 
S  Ground_Unit_DateV01 
B  Ground_MissionVO  1 

Ground_Mission_VehidesV01 


Figure  28.  Ground  Application  Module 


COMBO  PAGE 
1.  View  Objects 
a.  Combo  JUnitIDVO 

SELECT  FrUnit_EO . FR_UNIT_ID, FrUnit_EO . FR_UN I T_CTR Y_CD , 
TcptUnits_EO . ID,  TcptUni t s_EO . NAME  FROM 
COMBINED_SCHEMA . FROBDB_FR_UNIT 

FrUnit_EO , COMBINED_SCHEMA . TCPT_UNITS  TcptUnits_EO  WHERE 
FrUnit_EO . Fr_Unit_ID  =  TcptUni ts_EO . Name 


b.  Combo  _ParentUnitVO 

SELECT  FrUnit_EO . FR_UNIT_ID,  FrUnit_EO . FR_UN I T_CTR Y_CD , 
TcptUnits_EO . ID,  TcptUni ts_EO . NAME  FROM 
COMBINED_SCHEMA . FROBDB_FR_UNIT  FrUnit_EO, 
COMBINED_SCHEMA . TCPT_UNITS  TcptUnits_EO  WHERE 
FrUnit_EO . Fr_Unit_ID  =  TcptUnits_EO . Name 

•  Transient  Attributes 

1 .  Total  Air  Mi  s  sions 

Type:  Number 
UI  Hint/Format  Type:  None 
Groovy  Expression: 

Combo_ParentUnit_AirMissionVO.count("MsnWwId") 

2.  Total  Ground  Missions 

Type:  Number 
UI  Hint/Format  Type:  None 
Groovy  Expression: 


Combo_ParentUnit_GroundMissionsVO.count("MissionId") 


3.  Total  Missions 

Type:  Number 
UI  Hint/Format  Type:  None 

Groovy  Expression:  TotalAirMissions  +  TotalGroundMissions 

4.  Average  Air  Mission  Usage 

Type:  Number 

UI  Hint/Format  Type:  Percentage 
Groovy  Expression: 

Combo_ParentUnit_AirMis  sion  VO .  avg( "  Mi  s  sionUs  agePercent " ) 

5.  Average  Ground  Mission  Usage 

Type:  Number 

UI  Hint/Format  Type:  Percentage 
Groovy  Expression: 

Combo_ParentUnit_GroundMissionsVO.avg("MissionUsagePerce 

nt") 

6.  Average  Mission  Usage 

Type:  Number 

UI  Hint/Format  Type:  Percentage 
Groovy  Expression: 

(AvgAirMissionUsage  +  AvgGroundMissionUsage)/2 

7.  Red  Ground  Mission  Usage 

Type:  Number 

UI  Hint/Format  Type:  Number 
Label:  0-60% 

Groovy  Expression: 

Combo_ParentUnit_GroundMissionsVO.count("MissionUsage  != 
null  &&  MissionUsage  <  60  ?  MissionUsage  :  null") 

8.  Green  Ground  Mission  Usage 

Type:  Number 

UI  Hint/Format  Type:  Number 
Label:  81-100% 
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Groovy  Expression: 

Combo_ParentUnit_GroundMissions V O .count(" Mis sionUsage  ! = 
null  &&  MissionUsage  >  80  ?  MissionUsage  :  null") 

9.  Yellow  Ground  Mission  Usage 

Type:  Number 

UI  Hint/Format  Type:  Number 
Label:  61-80% 

Groovy  Expression: 

Combo_ParentUnit_GroundMissions  V O  .count("  Mis  sionUsage  ! = 
null  &&  MissionUsage  >  60  &&  MissionUsage  <  80  ? 
MissionUsage  :  null") 

10.  Red  Air  Mission  Usage 

Type:  Number 

UI  Hint/Format  Type:  Number 
Label:  0-60% 

Groovy  Expression: 

Combo_ParentUnit_AirMissionVO.count("MissionUsage  !=  null 
&&  MissionUsage  <  60  ?  MissionUsage  :  null") 

11.  Green  Air  Mission  Usage 

Type:  Number 

UI  Hint/Format  Type:  Number 
Label:  81-100% 

Groovy  Expression: 

Combo_ParentUnit_AirMissionVO.count("MissionUsage  !=  null 
&&  MissionUsage  >  80  ?  MissionUsage  :  null") 

12.  Yellow  Air  Mission  Usage 

Type:  Number 

UI  Hint/Format  Type:  Number 
Label:  61-80% 

Groovy  Expression: 

Combo_ParentUnit_AirMissionVO.count("MissionUsage  !=  null 
&&  MissionUsage  >  60  &&  MissionUsage  <  80  ?  MissionUsage  : 
null") 

c.  Combo  _ParentUnit_GroundMissionsVO 

SELECT  TcptUnits_EO . PARENT_ID,  TcptUni t s_EO . ID, 
TcptUni t s_EO . NAME ,  TcptMission_EO . ID  AS  ID1, 
TcptMission_EO . ARRIVAL_TIME , 
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TcptMission_EO . ORGANIZATION_ID  FROM 
COMBINED_SCHEMA . TCPT_UNITS  TcptUnits_EO, 
COMBINED_SCHEMA . TCPT_MISSION  TcptMission_EO  WHERE 
TcptUnits_EO . ID  =  TcptMission_EO . ORGANIZATION_ID 


•  Transient  Attributes 

1.  Mission  Usage 

Type:  Number 
UI  Hint/Format  Type:  None 

Groovy  Expression:  Ground_MissionVO.("TotalUsage") 

2.  Mission  Usage  Percent 

Type:  Number 

UI  Hint/Format  Type:  Percentage 

Groovy  Expression:  Ground_MissionVO.("TotalUsagePercent") 

d.  Combo  _ParentUnit_AirMission  VO 

SELECT  FrUnit_EO . FR_UNIT_PARENT_ID , 

FrUnit_EO . FR_UN I T_CTR Y_CD ,  FrUnit_EO . FR_UNIT_ID, 
Msn_EO.MSN_WW_ID,  Msn_EO . TASKED_FR_UNIT_ID , 

AbpReq_EO . ABP_REQ_NLT_DTTM ,  AbpReq_EO . ABP_WW_ID , 
AbpReq_EO . ABP_REQ_ID  FROM 

COMBINED_SCHEMA . FROBDB_FR_UNIT  FrUnit_EO, 
COMBINED_SCHEMA . ATOPLN_MSN  Msn_EO , 

COMBINED_SCHEMA . ATOPLN_ABP_REQ  AbpReq_EO  WHERE 
FrUnit_EO . FR_UNIT_ID  =  Msn_EO . tasked_f r_unit_id  AND 
Msn_EO.MSN_WW_ID  =  AbpReq_EO . MSN_WW_ID 


•  Transient  Attributes 

1.  Mission  Usage 

Type:  Number 
UI  Hint/Format  Type:  None 

Groovy  Expression:  Air_Mission_DetailsVO.("Total_Usage")*100 

2.  Mission  Usage  Percent 

Type:  Number 

UI  Hint/Format  Type:  Percentage 

Groovy  Expression:  Air_Mission_DetailsVO.("Total_Usage") 
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Combo.ParenlUnl  _At  MntonVO 
FiUnTParentd  Strng 
FrlXCtryCd  Sling 
FiUntld  String 
MsriVTtotd  St  mg 
TaslerftUnUd  Strng 
AboPeqMtDltm  Tmestamp 
AbtAVwld  Sling 
AboF«*l  SJmg 
lAssttnUsage  Nrnbet 
FtesionUsagePercert :  Number 


Co  mbo Pa  rent Ai  rVL 


1  to  Many 


Q  model  view 

Combo  _ParertUn(VO 
F  i  Undid  Siring 
FrUmCtiyCd  Sling 
id  BtgDoonol 

( TotalAilAjaonj  Number 

TotalGroun<fAs**ons  Nimbtr 
Tolar** sion  Nunber 
AvgAiMssionOsage  Number 
AvgGioundMssionlisage  tiirbei 
A  v  g»  AisionUvage  Number 
PedGroincf.UtionUsage  Nurt* 


Con*o_P»er*Unl_GroindM*siona'. 
Parent  id  BigOecmai 


Combo  Parent  GroundVL 


1  to  Many 


Name  Sbng 
*  MsiHrid  BgDecmal 


A/ixalTme  Tmettamp 
Oganrdwnid  BgDeomm 
JMstanUsage  Number 
MsacnOsagePercent  Number 


itpi  i  Ir 


1 - *  GreenGroundMstronUsage  Njmb< 

< e4o  wGroindMttionUiage  Numt 

1 

i 

|  Combo  Ground  MissionVL  1 1 

1  Combo  Air  MissionVL  I 

ZA 

1.  fe*owA«Mss*onU*age  Number 

m 

A*  JAssonVO 
TasledFrUrnid  Sling 
MsrWwW  smng 
AbpWwtd :  Strng 
AsrPeqW  Strng 
AbpWwldl  Strng 
AbpFe<£J  Strng 
■MsnVAvkll  Strng 
AsiMsrPigkl  Slrng 
Arnold  tleger 
AbpPeqWOltm  Timestamp 
AbpWwtd;  Strng 
AbpPe<*J1  Slrng 
ManCalCd  Sting 
TdaUsage  Number 
TotalUsagePercent  Mimbet 


model  view 
Ground  JAsMonVO 
Orgarwatnrtd  B^pecsnal 
Id  ftgDecimb 
AmvalTme  Tmeslamp 
Destnobon  Slrng 
lAssionOisTance  Strng 
Idl  BgDecmal 
Name  String 
vehrdeCoirt  Number 
TotalCargo  Number 
Tot  a#5  a  ■  Number 
(AssaonSpeceUsage  Numb 


l*»slor*VelgttUsage  Nimt 
TotaAlsage  Number 
TotalJsagePercenl  Numb# 


This  shows  the  view  objects  and  view  links  used  to  build  the  combo  page. 


Figure  29.  Combo  Page  View  Object  and  View  Link  Relationship 

2.  View  Links 

a.  Combo  JUnitIDVO  to  Combo _ParentUnitVO 

Source:  Combo_UnitIDVO.FrUnitId 
Destination:  Combo_ParentUnitVO.FrUnitId 
Cardinality:  1  to  many 

b.  Combo _ParentUnitVO  to  Combo _ParentUnit_AirMissionVO 

Source:  Combo_ParentUnitVO.FrUnitId 

Destination:  Combo_ParentUnit_AirMissionVO.FrUnitParentId 

Cardinality:  1  to  many 

c.  Combo _ParentUnit_AirMissionVO  to  Air_Mission_DetailsVO 

Source:  Combo_ParentUnit_AirMissionVO.MsnWWId 
Destination:  Air_Mission_DetailsVO.MsnWWId 
Cardinality:  1  to  1 
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d.  Combo _ParentUnitVO  to  Combo _ParentUnit_GroundMissionVO 

Source:  Combo_ParentUnitVO.Id 

Destination:  Combo_ParentUnit_GroundMissionsVO 

Cardinality:  1  to  many 

e.  Combo _ParentU nit jGroundMissionsVO  to  Ground _MissionVO 

Source:  Combo_ParentUnit_GroundMissionsVO.MissionId 
Destination:  Ground_MissionVO.Id 
Cardinality:  1  to  1 

3.  Application  Module 

The  combo  application  module  should  be  built  as  shown  in  Figure  30. 


Data  Model: 


Combo 


S  Combo_ParentUnitV01 

B  £51  Combo_ParentUnlt_AirMisslonVO  1 
£5]  Alr_Mission_DetailsVO  1 
S  Combo_ParentUnit_GroundMissionsV01 

Ground_MissionV01 
B  ComboJJnitIDVO  1 

B  Combo_ParentUnitV02 

Combo_ParentUnit_AirMissionV02 

Combo_ParentUnit_GroundMissionsV02 


Figure  30.  Combo  Application  Module 
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APPENDIX  D. 


This  appendix  will  provide  the  reader  with  the  general  steps  needed  in  order  to 
recreate  the  Transportation  Capacity  tool. 

A.  GENERAL  STEPS 

1.  Create  A  New  Application  in  JDeveloper. 

1.  Select  General,  Applications,  ADF  Fusion  Wed  Application. 

2.  Name  the  Application,  model  project  and  view  controller  project 
appropriately. 

3.  Select  all  default  Java  settings. 

4.  Select  Finish. 


Applications 

Databases 

i — i  — 

ml  Thesis_Fina 

w 

d  Projects 

0-jS]  7hesis_Final_Model 
6  CD  Application  Sources 
$  If)  model 
IB  I®  model. entity 
ijl  fjjjD  model, module 
IB  l@l  model. view 
££){□]  Thesis_Final_ViewController 


Figure  31.  Application  Project  Window. 

2.  Create  a  Connection  in  JDeveloper  to  the  Database  with  the  Tables 
Listed  in  Appendix  B. 

1.  Select  Create  a  Database  Connection. 

2.  Select  IDE  Connections  (in  order  to  use  the  connection  in  multiple 
applications,  if  desired)  or  select  the  Application  Name. 
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3. 


Name  connection. 


4.  Connection  Type:  Oracle  (JDBC). 

5.  Username,  Password  and  role  will  be  unique  to  the  database  used. 

6.  Oracle  JDBC  settings  can  be  left  as  default. 

B.  BUILDING  THE  MODEL  PROJECT 

1.  Create  Entity  Objects  for  Tables  Listed  in  Appendix  B. 

1.  In  the  Model  project,  create  new  business  components  from  tables. 

2.  Select  the  appropriate  schema  and  tables. 

3.  Toggle  all  necessary  tables  and  rename  if  required. 

4.  Rename  Entity  objects  in  accordance  with  the  organizations  naming 
conventions. 

5.  For  this  application,  there  were  no  entity-based  View  objects  or  Query- 
based  view  objects  created. 

6.  Add  selected  tables  to  the  application  module. 

7.  Once  finished,  all  Entity  objects  and  corresponding  associations  (based  off 
of  primary  and  foreign  keys)  will  be  created  under  the  model.entity  tab. 
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0  jo]  Thesis_Final_Model 
B-CU  Application  Sources 
0  tfgl  model 
a  m  model. entity 
j  0  TgJ  Abp_EO 
0  ^  AbpFkAssoc 
0  CgJ  AbpReq_EO 
0  ^  AbpReqAbpFkAssoc 
0  AircraftDetails_EO 
0  [gj  AirMsn_EO 
0  AirMsnAcft_EO 
0  ^  AirmsnFkAssoc 
0  Cg}  Asr_EO 
0  ^  AsrAsrfkAssoc 
0  AsrMsnPrg_EO 
0  C^l  AsrMsnPrgMsnFkAssoc 
0  CapabilityTypeCapTypeCatAssoc 
0  EquipmentUnitAssignldFkAssoc 
0  ^  EquipmentUnitldAttachFkAssoc 
0  ^  FkAbpReqAssoc 
0  FkCapabilityTypeAssoc 
0  FkEqcapabilitiesEquipmentAssoc 
0^1  FkEquipmentModelidAssoc 

lit  Ei  FkFni  linmpntT^mmirlAccnr 

Figure  32.  Entity  Objects 


2.  Create  View  Objects  as  Identified  in  Appendix  C. 

1.  In  the  model  project,  create  new  view  object. 

2.  Name  view  object  as  identified  in  Appendix  C. 

3.  Data  source  will  be  Entity  Object. 

4.  Under  the  entity  objects  tab,  select  the  appropriate  entity  objects  as 
identified  in  Appendix  C. 

5.  It  is  important  that  the  entity  objects  are  adding  in  the  same  order  as 
shown  in  the  appendix. 

6.  When  there  is  a  relevant  association,  the  ‘Join  Type’  field  will  become 
updatable.  This  field  should  be  changed  to  ‘inner  join’  for  all  view  objects. 

7.  Unselect  the  ‘updatable’  field.  This  application  will  run  as  a  read-only 
application. 


99 


8.  Under  the  attributes  tab,  select  the  appropriate  attributes  as  identified  in 
Appendix  C. 

9.  Rename  View  objects  and  attributes  in  accordance  with  the  organizations 
naming  conventions. 

10.  No  attribute  settings  were  changed  in  this  application. 

11.  Under  the  ‘Query’  tab,  insert  all  WHERE  and  ORDER  BY  statements  as 
shown  in  Appendix  C. 

12.  No  bind  variables  were  added. 

13.  Java  settings  were  kept  as  default. 

14.  Add  View  objects  to  the  application  module. 

15.  Once  added,  all  view  objects  will  be  visible  under  the  model. view  tab. 

d  Projects  §3  SB ”  Y  ’  3s:  ” 

@  |Jaj  Thesis_Final_Model 
E  C]  Application  Sources 
QD  [jjjl  model 
ffl  ®  model,  entity 
(j  S3)  model. module 
6  [jjp  model. view 

Gp  §5]  Air_Mission_DetailsVO 

ffl  £9  Air_MissionVO 

Gp  Air_Unit_DateVO 

E  £9  Air_Unit_InfoVO 

$  £9  Combo_ParentUnit_AirMissionVO 

ffi  £9  Combo_ParentUnit_GroundMissionsVO 

$  £9  Combo_ParentUnitVO 

$  £9  ComboJJnitIDVO 

ij  £9  Ground_Mission_VehidesVO 

El  £9  Ground_MissionVO 

ji  £9  Ground_Unit_DateVO 

E  £9  Ground_Unit_InfoVO 

Figure  33.  View  Objects 

3.  Create  View  Links  between  the  View  Objects 

1 .  Under  the  model  project,  select  new  view  link. 

2.  Name  the  view  link  as  shown  in  Appendix  C. 

3.  Select  the  source  attribute,  destination  attribute,  and  cardinality  as  shown 
in  Appendix  C.  Select  add  to  bind  the  view  objects. 
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4.  Default  settings  were  selected  in  the  view  link  properties,  edit  source 
query,  and  edit  destination  query. 

5.  Add  the  view  links  to  the  model  module. 

6.  Once  finished,  all  view  links  will  be  visible  under  the  model. module  tab. 


0  0  Thesis_Final_Model 
I  Q  Application  Sources 
0  ffj)  model 
I  if  model. entity 
0  #  model. module 
I  IS  Air 

Efi  gai  Air_Mission_MissionDetailsVL 
0  ££l  Air_Unit_UnitDateVL 
0  ^1  Air_UnitDate_MissionVL 
0  jfi|  Combo 

0  Combo_AirMission_MissionVL 
0  £§  Combo_GroundMission_MissionVL 
|  0  Combo_ID_VL 

0  tjj  ComboParentName_AirMissionVL 
0  ComboParentName_GroundMissionVL 
0  iFfa  Ground 

0  ^1  Ground_Mission_MissionVehidesVL 
0  ^1  Ground_Unit_UnitDateVL 
0  Ground_UnitDate_MissionVL 

Figure  34.  View  Links 

4.  Create  All  Required  Transient  Attributes  in  the  View  Objects 

1.  Select  a  view  object  that  requires  a  transient  attribute. 

2.  Select  the  attributes  tab. 

3.  Select  the  green  ‘+’  button  and  select  new  attribute. 

4.  Name  the  attribute  and  select  the  appropriate  type.  For  this  application,  all 
transient  attributes  created  were  Number. 

5.  Once  added,  change  default  value  to  ‘expression’  and  insert  groovy 
expressions  as  identified  in  Appendix  C. 

6.  Select  the  UI  Hints  tab,  and  change  format  type  as  identified  in  Appendix 
C. 
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5.  Create  an  Application  Module  for  Each  of  the  Different  Pages 
(Air,  Ground,  and  Combo)  in  Order  to  Test  the  View  Objects’ 
Functionality. 

1.  Under  the  model  project,  select  new  application  module. 

2.  Name  the  module  for  the  appropriate  page. 

3.  Under  the  data  model  tab,  toggle  the  appropriate  view  objects  in  the  order 
as  annotated  in  Appendix  C. 

4.  Java  settings  remain  as  default. 

5.  Once  the  application  modules  are  created  they  will  be  visible  under  the 
model.module  tab.  Use  the  application  modules  to  test  the  data  prior  to 
building  the  pages. 


d  Projects  m  S3  '■  V  ’  3°- 

Thesis_Final_Model 
1=)  CD  Application  Sources 
$  I®  model 
GB-'I®  model. entity 
0-®l  model.module 
j  E  Q|  Air 

ffi  Air_Mission_MissionDetailsVL 
El  ££l  AirJJnitJJnitDateVL 
1$  Alr_UnitDate_MissionVL 
Ei  I  hi  Combo 

SI  ?®)  Combo_AirMission_MissionVL 
El  Combo_GroundMission_MissionVL 
|  Si  ££1  Combo_ID_VL 

$-81  ComboParentName_AirMissionVL 
0^1  ComboParentName_GroundMissionVL 
Ei  tftl  Ground 

Si  Ground_Mission_MissionVehidesVL 
a  £0  Ground_Unit_UnitDateVL 
a  Ground_UnitDate_MissionVL 
a  I®  model. view 

Figure  35.  Application  Modules 


C.  BUILDING  THE  VIEW  CONTROLLER  PROJECT 
1.  Task  Flow 

1.  Under  the  View  controller  project,  select  new  ADF  Task  Flow. 
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2.  Unselect  ‘Create  as  bounded  task  flow’. 

3.  Name  task  flow  as  appropriate. 

4.  Drag  the  ‘View’  component  from  ‘Activities’  section. 

5.  Name  the  ‘View’  for  each  page  that  will  be  built  (There  should  be  5  views 
in  total) 

6.  Once  all  views  are  created,  select  the  ‘Control  Flow  Case’  from  the 
‘Control  Flow’  tab  and  select  the  starting  page  and  end  page.  Name  the 
flow  case  as  “Go  To  XX  Page”. 

7.  Link  all  views  with  control  flow  cases  as  shown  in  Figure  36. 


Figure  36.  Task  Flow 


8.  Once  the  .JSF  pages  are  built,  they  will  be  linked  back  to  each 

corresponding  view  by  select  the  ‘Page  *’  under  the  General  tab.  Enter  the 
title  of  the  page  as  shown  in  Figure  37. 
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view  -  viewl  -  Properties 

*  1  0 

CL  Find 

(2) 

1  El  General 

Figure  37.  Task  Flow  View  Properties 


2.  Home  Page 

1 .  Under  the  View  Controller  Project,  select  new  Page. 

2.  Name  the  page. 

3.  All  pages  in  this  application  used  the  format  in  Figure  38. 


Directory :  C :  \JDeveloper  Vny work\Thesis_Final  \Thesis_Final_ViewController  V>ublic_html 

Document  Type:  ®Facelets  0JSPXML 

Page  Layout  Managed  Bean 

0  Create  Blank  Page  Q  Reference  ADF  Page  Template  ®  Copy  Quick  Start  Layout 


3^ 


a 

|  |  Apply  color  theme  to  layout  components 

Figure  38.  Page  Layout 


Description 

One  Column  Header 
(Stretched  with 
Splitter) 

1 1 ,  Child  components  will 
be  stretched  to  fill 

Q  Fixed  (non -stretching) 

^  Splitter  showing 
collapse  direction 

=i  Scrollable  panel 


When  you  copy  a  Quick 
Start  Layout  into  your  page, 
you  can  delete  or  modify  the 
generated  components  as 
needed.  Unlike  a  template, 
there  is  no  permanent  link 
between  your  page  and  the 
layout  you  use  to  get 
started. 


4.  Under  the  first  facet  in  the  Vertical  panel  splitter,  drag  and  drop  the 
‘Image’  from  the  ‘General  Controls’  components. 

5.  In  the  source  field,  locate  an  image  that  can  be  used  as  the  application 
logo.  The  logo  used  for  this  application  was  a  generic  logo  saved  as  a  jpeg. 
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Figure  39  shows  the  correct  location  for  the  image.  This  image  was 
applied  in  the  same  manner  on  all  pages. 


Home.jsf  -  Structure 

n  & 

&  html 
Et  [ii|  f:view 

B  jS]  af: document -Home.jsf 
(3  HU  af:fbrm 

!  &□  afipanelSpiltter  -  vertical 

B  T*3  Panel  Splitter  facets 

B  aa  f:  facet  -  first 

!□!  af: image  -  #{...} 
m  f:  facet  -  second 
fi  'Q  Document  facets 

Figure  39.  Home  Page  Structure 

6.  Under  the  second  facet,  drag  and  drop  a  ‘Panel  Group  Layout’  from 
‘Layout’  tab. 

•  Under  the  ‘common’  properties: 

-  Halign:  Center. 

-  Valign:  Middle. 

-  Layout:  Horizontal. 

7.  Add  three  ‘buttons’  from  the  ‘General  Controls’  tab  to  the  ‘Panel  group 
layout’ . 

•  Each  button  should  be  named. 

•  Under  the  ‘Button  Action’  tab,  select  the  appropriate  action  for  each 
button. 

(1)  Button  Inline  Style:  height:  lOOpx;  width:  180px;  font- size :xx-large;  text- 
aligmcenter;  vertical-aligmbaseline;  line-height: 80px;  font-weight:bold; 
font-family:"  Arial  Black  color :#000052;  border-color:#000052;  border- 
width:thick; 

8.  Figure  40  shows  the  structure  of  the  second  facet  of  the  Home  page. 
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af:panelSplitter  -  vertical 
&'Q  Panel  Splitter  facets 
B  f:  facet  -  first 
b  ffl  f:  facet  -  second 

B  =a  af:panelGroupLayout  -  horizontal 
B  O  af:button  -  Air 
B  O  af:button  -  Ground 
B  O  afibutton  -  Combo 
H  f3  Panel  Group  Layout  facets 

Pta  ps _ i.  c _ i~_ 

Figure  40.  Home  Page  Structure 


3.  Air  Page 

1.  Create  a  new  page  using  the  same  format  as  above. 

2.  Add  the  logo  as  above. 

3.  Under  the  page’s  original  vertical  panel  splitter,  at  a  ‘Panel  Group  Layout’ 
and  configure  the  buttons  as  above. 

•  Buttons  for  the  subpages  will  have  the  following  properties: 

-  Button  Inline  Style:  height:50px;  width:90px;  font-size:large;  text- 
aligmcenter;  vertical-aligmbaseline;  line-height:40px;  font-weight:bold; 
font-family:"  Arial  Black  color:#000052;  border-color:#000052;  border- 
width:thick; 

4.  Those  two  sections  should  be  formatted  as  Figure  41. 
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af:  document  -  Air.jsf 
B  af:  messages 
[ii]  af:form 

bQ  af:panelSplitter  -  vertical 
B  Q  Panel  Splitter  facets 
B  ■  ffl  f:  facet  -  first 


f: image  -  #{...} 


B  f:  facet  -  second 

af:panelGroupLayout 
B  O  afibutton  -  Ground 
B  C3  afibutton  -  Combo 
B  O  af:button  -  Home 
B  Q  Panel  Group  Layout  facets 
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Figure  41.  Air  Page  Structure 


Under  the  second  facet,  add  a  ‘Panel  splitter’ . 
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5. 


Orientation:  Horizontal. 


•  Splitter  Position:  300. 

6.  Under  the  first  facet  of  the  second  splitter,  add  a  ‘Panel  Splitter’. 

•  Orientation:  Vertical. 

•  Splitter  Position:  300. 

7.  Under  the  first  facet  of  the  third  splitter,  add  a  ‘Panel  Box’  labeled  unit. 

•  Add  a  ‘Panel  Form  Layout’  by  dragging  the  ‘Air_Unit_InfoV01’  from  the 
Data  controls  tab. 

•  Select  ADF  Form. 

•  Select  ‘Read-only  form’  and  ‘row_navigation’. 

•  Delete  all  attributes  except  for  ‘FrUnitld’  and  ‘LocNm’ . 

•  Label  the  fields  Unit  and  Location. 

•  Select  ok.  The  structure  should  look  like  Figure  42. 

a  ■  □  afipanelSplitter  -  vertical 
a  Q  Panel  Splitter  facets 
0  33  f:  facet  -  first 
I  a  □  af:panelBox  -  Unit 

0  IH  afipanelFormLayout 

a  af:inputText  -  *{. . .FrUnitld. . .label} 
a  $3  af:inputText  -*{... LocNm. ..label} 
a  Cd  Panel  Form  Layout  facets 
a  Q  Panel  Box  facets 

Figure  42.  Air  Page  Structure 

8.  Under  the  second  facet  of  the  third  splitter,  add  a  ‘Panel  box’  labeled  date. 

•  Add  a  ‘Panel  Form  Layout’  by  dragging  the  ‘Air_Unit_DateV01’  from 

the  Data  controls  tab. 

•  Select  ADF  Form. 

•  Select  ‘Read-only  form’  and  ‘row_navigation’ . 

•  Delete  all  attributes  except  for  ‘AbpReqNLTDTTM’ . 

•  Label  the  field:  Mission  Date. 
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•  The  structure  should  look  like  the  Figure  43. 

B  □  afipanelSplitter  -  vertical 
B-Q  Panel  Splitter  facets 
B  IE  f:  facet  -  first 

f:  facet  -  second 
bQ  afipanelBox  -  Date 
B  [i§  afipanelFormLayout 

®  EeD  afiinputDate  -  Mission  Date 
b  PT  Panel  Form  Layout  facets 
fi  Q  Panel  Box  facets 

Figure  43.  Air  Page  Structure 

9.  Under  the  second  facet  of  the  second  splitter,  add  a  ‘Panel  Splitter’ . 

•  Orientation:  Vertical. 

•  Splitter  position:  300. 

10.  Under  the  first  facet  of  the  fourth  splitter,  add  a  ‘Panel  box’  labeled 
Mission. 

•  Add  a  ‘table’  by  dragging  the  ‘Air_MissionV01’  from  the  Data  controls 
tab. 

•  Select  ADF  Table. 

•  Select  ‘Read-only  form’  and  ‘row_navigation’ . 

•  Delete  all  attributes  except  for  ‘MsnWWId’  ‘AbpWWId’  ‘AsrReqld’ 
‘MsnCatCD’  and  ‘MissionUsage’. 

•  Label  the  fields  Mission  Id,  ABP  ID,  ASR  #,  Mission  Category  and 
Mission  Usage,  respectively. 

•  Add  an  additional  column  to  the  table  and  label  it  Usage  meter. 

-  Drag  and  drop  a  ‘Gauge’  into  this  column. 

-  The  properties  should  be  set  as  shown  in  Figure  44. 
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B  Common 

Rendered: 
o  Id: 

o  GaugeType: 
GaugeSetColumnCount: 
GaugeSetAlignment: 
GaugeSetDirection : 

9  Value: 

B  Gauge  Data 
9  Value: 

TabularData: 
o  Min  Value: 
o  MaxValue: 


-  Under  the  ‘ThresholdSet’  tab,  add  three  thresholds. 
Threshold  1: 

-Fill  color:  #ff0000. 

-  ThresholdMaxValue:  60.0. 

Threshold  2: 

-  Fill  color:  #ffff00. 

-  ThresholdMaxValue:  80.0. 

Threshold  3: 

-  Fill  color:  #00ff00. 

-  ThresholdMaxValue:  100.0. 

-  Under  the  metric  label,  change  number  type  to  ‘NT_Percent’. 
•  The  structure  should  look  like  Figure  45. 


Figure  44.  Gauge  Properties 
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0  □  afipanelSplitter  -  vertical 
B  Q  Panel  Splitter  facets 
0  f:  facet  -  first 

|  □  afipanelBox  -  Mission 

&  S  af:table  -  tl 

0  §  af: column  -  *{...MsnWwId. label} 
@  |  af : column  -  *{...AbpWwId. label} 
0  §  af : column  -  if  {...AsrReqld. label} 
0  §  af : column  -  *{...MsnCatCd. label} 
0  §  af: column -Mission  Usage 
0  §  afxolumn  -  Usage  Meter 
0  Q  dvt:  gauge 
I  9  -0  dvtigaugeBackgrounc 

: . ^  dvt:spedalEffects 

00  dvt:thresholdSet 
[•"  ^  dvt:  threshold 
f-  &  dvt:  threshold 
:  dvt:  threshold 

i . 0  dvt:topLabel 

<&  dvt:metricLabel 
dvt:bottomLabel 
0  lJ  Gauge  facets 

Figure  45.  Air  Page  Structure 


1 1 .  Under  the  second  facet  of  the  fourth  splitter,  add  a  ‘Panel  Box’  labeled 

Mission  Details. 

•  Add  a  ‘Panel  Format  Layout’  by  dragging  the  ‘Air_Mission_DetailsV01’ 
from  the  Data  controls  tab. 

•  Select  ADF  Form. 

•  Select  ‘Read-only  form’  and  ‘row_navigation’ . 

•  Delete  all  attributes  except  for  ‘AsrUnitCalledNM’  ‘AsrReqlD’ 

‘AirMsnTakeoffLocNm’  ‘AirMsnLandingLocNm’  ‘AcftMdsTypeCd’ 
‘AirMsnAcftAircraftQty’  ‘AsrPyldlntCargoWt’  ‘AsrPyldExtrCargoWt’ 
‘  AsrPy  ldTroopT  x  ’  ‘Asr_Int_Pyld’  ‘Asr_Ext_Pyld’  ‘Asr_Pax’ 

‘Total_usage’. 

•  Label  the  fields  Unit  Supported,  AsrReqld,  Takeoff  Location,  Landing 
Location,  A/C  Type,  A/C  Qty,  External  Cargo  Weight  (Lbs),  Internal 
Cargo  Weight  (Lbs),  Pax,  Internal  Usage,  External  Usage,  Pax  Usage, 
Total  Usage,  respectively. 

•  The  structure  should  look  like  Ligure  46. 
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am  afipanelSplitter  -  vertical 
B  'Q  Panel  Splitter  facets 

©  S3  f:  facet  -  first 

Bffl  f:  facet  -  second 

S  fl  af:panelBox  -  Mission  Details 
©  [II]  afipanelFormLayout 

©  $3  af:inputText  -  *{. . . AsrllnitCalledNm . . . label} 

©  [Jd  af:inputText  -  #{. . . AsrReqld. .  .label} 

©•■  ©□  af:inputText  -  #{. . .  AirMsnTakeoffLocNm, .  .label} 

©  af:inputText  -  *{...AirMsnLandingLocNm...  label} 

©  af:inputText  -  *{. .  .AcftMdsTypeCd. .  .label} 

©  af:inputText  -  #{. . . AirMsnAcftAircraftQy . .  .label} 

©  ijn  af:inputText  -  *{. . . AsrPyldExtrCargoWt. .  .label} 

©  ijn  af:inputText  -  ~{. . . AsrPyldlntCargoWt. .  .label} 

©■•■$3  af:inputText  -  *{. . . AsrPyldTroopTx. .  .label} 

©  [£□  af:inputText  -  #{. . . Asr_Int_Pyld. . .label} 

©  (|zi  afiinputText  -  *{. .  .Asr_Ext_Pyld. . .label} 

©  i£j  af:inputText  -  *{...Asr_Pax... label} 

©■•■$□  af:inputText -#{... TotalJJsage...  label} 

©  Q  Panel  Form  Layout  facets 
©  5)  Panel  Box  facets 

Figure  46.  Air  Page  Structure 

12.  The  final  structure  of  the  Air  page  should  look  like  Figure  47. 


Ill 


B  |S|  af: document  -  Air. jsf 

f . %  af:  messages 

B  IH  af:form 

!  af:panelSplitter  -  vertical 

S  Q  Panel  Splitter  facets 
B'ffl  f:  facet  -  first 

!□)  af: image  -  #{...} 

B  Ffl  f:  facet  -  second 

s-m  af:panelSplitter  -  horizontal 
b  Q  Panel  Splitter  facets 
B  §3  fifecet  -  first 

B  TT1  af:panelSplitter  -  vertical 
B  Q  Panel  Splitter  facets 
Iffl  f:  facet  -  first 

ISTI  af:panelBox  -  Unit 
B-  f:  facet  -  second 

S  □  af:panelBox  -  Date 
B  ^  f:facet  -  second 

S"[j]  af:panelSplitter  -  vertical 
B  Q  Panel  Splitter  facets 
B  H  f:facet  -  first 
I  B  □  af:panelBox  -  Mission 
B  Q3  f:facet  -  second 

B  Q  af:panelBox  -  Mission  Details 

B  ^  af:panelGrouplayout 
B  CJ  af:  button  -  Ground 
B  CJ  af: button  -  Combo 
B  CJ  af:  button  -  Home 
B  Q  Panel  Group  Layout  facets 

^  P-X  r~.  .  r 

Figure  47.  Air  Page  Structure 

D.  GROUND  PAGE 

1.  Create  a  new  page  using  the  same  format  as  above. 

2.  Add  the  logo  as  above. 

3.  Under  the  page’s  original  vertical  panel  splitter,  at  a  ‘Panel  Group  Layout’ 
and  configure  the  buttons  as  above. 

•  Buttons  for  the  subpages  will  have  the  following  properties. 

-  Button  Inline  Style:  height:50px;  width:90px;  font-size:large;  text- 
aligmcenter;  vertical-aligmbaseline;  line-height:40px;  font-weight:bold;  font- 
family:"  Arial  Black  color:#000052;  border-color:#000052;  border-width:thick; 

4.  Those  two  sections  should  be  formatted  in  Figure  48. 
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S  |S|  af : document  -  Ground. jsf 

| . ^jg]  af:messages 

B  [0]  afiform 

il'D  af:panelSplitter  -  vertical 
B  Q  Panel  Splitter  facets 
B  f:  facet  -  first 

B  af:image  -  #{...} 

B  f:  facet  -  second 

B  =a  af:panelGroupLayout 
B  C3  af:  button  -  Air 
B  LJ  af: button  -  Combo 
B  □  af:  button  -  Home 
B  Q  Panel  Group  Layout  facets 

Figure  48.  Ground  Page  Structure 

5.  Under  the  second  facet,  add  a  ‘Panel  splitter’. 

•  Orientation:  Horizontal. 

•  Splitter  Position:  300. 

6.  Under  the  first  facet  of  the  second  splitter,  add  a  ‘Panel  Splitter’ . 

•  Orientation:  Vertical. 

•  Splitter  Position:  300. 

7.  Under  the  first  facet  of  the  third  splitter,  add  a  ‘Panel  Box’  labeled  unit. 

•  Add  a  ‘Panel  Form  Layout’  by  dragging  the  ‘Ground_Unit_InfoV01’ 
from  the  Data  controls  tab. 

•  Select  ADF  Form. 

•  Select  ‘Read-only  form’  and  ‘row_navigation’ . 

•  Delete  all  attributes  except  for  ‘Id’  and  ‘ShortName’ . 

•  Label  the  fields  Unit  Id  and  Name. 

•  Select  ok.  The  structure  should  look  like  Figure  49. 
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af:panelSplitter  -  vertical 
&  &  Panel  Splitter  facets 
Bffl  f:  facet  -  first 
|  BO  af:panelBox  -  Unit 

Q-  [Hj  afipanelFormLayout 

©  [£□  afiinputText  -  *{...  Id...  label} 

©$3  af:inputText  -  #{...ShortName... label} 

S  'Q  Panel  Form  Layout  facets 

Figure  49.  Ground  Page  Structure 

Under  the  second  facet  of  the  third  splitter,  add  a  ‘Panel  box’  labeled  date. 

Add  a  ‘Panel  Form  Layout’  by  dragging  the  ‘Ground_Unit_DateV01’ 
from  the  Data  controls  tab. 

Select  ADF  Form. 

Select  ‘Read-only  form’  and  ‘row_navigation’ . 

Delete  all  attributes  except  for  ‘ArrivalTime’. 

Label  the  field:  Mission  Date. 

The  structure  should  look  like  Figure  50. 


bO  af:panelSplitter  -  vertical 
B  O  Panel  Splitter  facets 
B -  ^  f:  facet  -  first 
!  ®  □  af:panelBox  -  Unit 

Bffl  f:  facet  -  second 

sO  afipanelBox  -  Date 
&  H]  af:panelFormLayout 

©  Es"3  af:inputDate  -  *{... ArrivalTime... label} 

©  P~l  Panel  Form  Layout  facets 
©  Q  Panel  Box  facets 

Figure  50.  Ground  Page  Structure 
Under  the  second  facet  of  the  second  splitter,  add  a  ‘Panel  Splitter’ . 
Orientation:  Vertical. 

Splitter  position:  300. 

Under  the  first  facet  of  the  fourth  splitter,  add  a  ‘Panel  box’  labeled 
Mission. 

Add  a  ‘table’  by  dragging  the  ‘Ground_MissionV01’  from  the  Data 
controls  tab. 


Select  ADF  Table. 


•  Select  ‘Read-only  form’  and  ‘row_navigation’ . 

•  Delete  all  attributes  except  for  ‘Id’  ‘ArrivalTime’  ‘Destination’ 
‘MissionDistance’  ‘VehicleCount’  ‘TotalCargo’  ‘TotalPax’ 
‘MissionSpaceUsage’  ‘MissionPaxUsage’  ‘MissionWeightUsage’ 
‘MissionUsage’. 

•  Label  the  fields  Mission  Id,  Mission  Date,  Destination,  Mission  Distance, 
#  of  Vehicles,  Total  Cargo,  Total  Pax,  Mission  Space  Usage,  Pax  Usage, 
Weight  Usage,  and  Mission  Usage,  respectively. 

•  Add  an  additional  column  to  the  table  and  label  it  Usage  meter 

-  Drag  and  drop  a  ‘Gauge’  into  this  column 

-  The  properties  should  be  set  as  shown  in  Figure  5 1 . 


El  Common 

Rendered: 

°  Id: 

o  GaugeType: 

GaugeSetColumnCount: 

GaugeSetAlignment: 

GaugeSetDirection: 

9  Value: 

B  Gauge  Data 
9  Value: 

TabularData: 
o  Min  Value: 
o  MaxValue: 

Figure  5 1 .  Gauge  Properties 

-Under  the  ‘ThresholdSet’  tab,  add  three  thresholds. 
-Threshold  1: 

-  Fill  color:  #ff0000 

-  ThresholdMaxValue:  60.0 
-Threshold  2: 

-  Fill  color:  #ffff00 
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-  ThresholdMaxValue:  80.0 
-  Threshold  3: 

-  Fill  color:  #00ff00 

-  ThresholdMaxValue:  100.0 

-Under  the  metric  label,  change  number  type  to  ‘NT_Percent’ . 
•  The  structure  should  look  like  Figure  52. 


a  LU  af:panelSplitter  -  vertical 
&  Q  Panel  Splitter  facets 
eBB  f:  facet  -  first 
!  B'O  af:panelBox  -  Mission 
0  IH  af:table  -  tl 

B  §  af:column  -#{... Id. label} 

|  af: column  - ArrivalTime. label} 

B-  |  af: column  -*{... Destination. label} 

B  §  af : column  -  *{...MissionDistance. label) 
i'  l  af : column  -  #{..,VehideCount. label} 
i'  l  af: column  -  *{,..TotalCargo. label} 

B  §  af:column  -  *{,..TotalPax. label} 

B'  i  af : column  -  #{...MissionSpaceUsage. label} 

B  §  af : column  -  *{...MissionPaxUsage. label} 

®  -  |  af: column  -  *{...MissionWeightl)sage. label} 

B  §|  af:  column  -  Mission  Usage 
B  §  af:column  -  Usage  Meter 
B  CD  Table  facets 

Figure  52.  Ground  Page  Structure 

1 1 .  Under  the  second  facet  of  the  fourth  splitter,  add  a  ‘Panel  Box’  labeled 
Mission  Details. 

•  Add  a  ‘Table’  by  dragging  the  ‘Ground_Mission_VehiclesV01’  from  the 
Data  controls  tab. 

•  Select  ADF  Table. 

•  Select  ‘Read-only  form’  and  ‘row_navigation’ . 

•  Delete  all  attributes  except  for  ‘Masterld’  ‘Equipmentld’  ‘Nomenclature’ 
‘MilesTraveled’  ‘FuelUsed’  ‘Passengers’  ‘CargoWeight’  ‘Description’ 
‘Qty’  ‘WeightCapacity’  ‘PassengerCapacity’  and  ‘SpaceCapacity’. 

•  Label  the  fields  Master  ID,  Equipment  ID,  Nomenclature,  Miles  Traveled, 
Fuel  Used,  Pax,  Cargo  weight,  Cargo  Type,  Qty,  Weight  Usage,  Pax 
Usage,  Space  Usage,  respectively. 

•  The  structure  should  look  like  Figure  53. 
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6-  HI  af:panelSplitter  -  vertical 
©  [H  Panel  Splitter  facets 
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B  Q  af:panelBox  -  Missoin  Vehicles 
© -  IS  af:  table  - 12 
© 

!  ©  • 

I  ©' 

!  ©  • 

I  i- 
:  ©  • 

I  ©• 

I  ©  • 

I  ©  • 
i  ©••• 

I  ©  • 

j  ©  ' 
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a  □ 

Figure  53.  Ground  Page  Structure 

12.  The  final  structure  of  the  Ground  page  should  look  like  the  Figure  54. 


y  af:  column  -  *{. 
y  af:  column  -  #{. 
y  af:  column  -  *{. 
y  af:  column  -  *{. 
y  af: column  -  -{. 
y  af:  column  -  *{. 
y  af:  column  -  #{. 
y  af:  column  -  #{. 
y  af:  column  -  #{. 
y  af:  column  -  *{. 
y  af:  column  -  #{. 
y  af:  column  -  *{. 
n  Table  facets 
Panel  Box  facets 


.Masterld.  label} 
.Equipmentld.  label} 

.  Nomenclature .  label} 

.  MilesTraveled .  label} 
.FuelUsed.  label} 
.Passengers,  label} 

.  CargoWeight.  label} 
.Descrip  ton.  label} 

•Qty.  label} 

.WeightCapacity. label} 

.  PassengerCapacity .  label} 
.  SpaceCapadty .  label} 
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B  [j§]  af : document  -Ground .jsf 

-  af:  messages 

©-  §§  af:fbrm 

|  B  □  af:panelSplitter  -  vertical 
S  Q  Panel  Splitter  facets 
b  m  f:  facet  -  first 

[□I  af: Image  -#{...} 

B  a  f:  facet  -  second 

B-Q]  af:panelSplitter  -  horizontal 
B  Q  Panel  Splitter  facets 
S  S3  f:  facet  -  first 
!  B  □  af:panelSplitter  -  vertical 
B  C~)  Panel  Splitter  facets 
Bffl  f:  facet  -  first 

af:panelBox  -  Unit 
B  a  f:  facet  -  second 

B  □  af:panelBox  -  Date 
B  a  facet  -  second 

bQ  afipanelSplitter  -  vertical 
B  Q  Panel  Splitter  facets 
sa  f:  facet  -  first 
i  B  □  af:panelBox  -  Mission 
bb  f:  facet  -  second 

B  □  af:panelBox  -  Missoin  Vehicles 

B  af:panelGroupLayout 
B-Q  af:button  -  Air 
B  O  af:button  -  Combo 
B  O  af:button  -  Home 
B  Q  Panel  Group  Layout  facets 

Figure  54.  Ground  Page  Structure 

E.  COMBO  PAGE 

1.  Create  a  new  page  using  the  same  format  as  above. 

2.  Add  the  logo  as  above. 

3.  Under  the  page’s  original  vertical  panel  splitter,  at  a  ‘Panel  Group  Layout’ 
and  configure  the  buttons  as  above. 

•  Buttons  for  the  subpages  will  have  the  following  properties. 

-  Button  Inline  Style:  height:50px;  width:90px;  font-size:large;  text- 
aligmcenter;  vertical-aligmbaseline;  line-height:40px;  font-weight:bold;  font- 
family:"  Arial  Black  color:#000052;  border-color:#000052;  border-width:thick; 

4.  Those  two  sections  should  be  formatted  as  seen  in  Figure  55. 
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£}  ID  af:document-  Combo. jsf 
|  af:  messages 

[si]  af:form 

|  B  □  af:panelSplitter  -  vertical 
B  CD  Panel  Splitter  facets 
f:  facet  -  first 
;  [□)  af:image  -  #{...} 

B  m  f:  facet  -  second 
B-=jj  af:panelGroupLayout 
©■■■□  af:button  -  Air 
B  O  af:button  -  Ground 
B  O  af:button  -  Home 
B  O  af:  button  -  Totals 
i  l  l  Panel  Group  Layout  facets 

Figure  55.  Combo  Page  Structure 

5.  Under  the  second  facet,  add  a  ‘Panel  splitter’. 

•  Orientation:  Vertical. 

•  Splitter  Position:  200. 

6.  Under  the  first  facet  of  the  second  splitter,  add  a  ‘Panel  Box’  labeled  unit. 

•  Add  a  ‘Panel  Form  Layout’  by  dragging  the  ‘Combo_ParentUnitV01’ 
from  the  Data  controls  tab. 

•  Select  ADF  Form. 

•  Select  ‘Read-only  form’  and  ‘row_navigation’. 

•  Delete  all  attributes  except  for  ‘FrUnitld’  ‘TotalAirMissions’ 

‘  A  vg  AirMis  sionU  s  age  ’  ‘  T  otalGroundMissions  ’ 

‘AvgGroundMissionUsage’  ‘TotalMissions’  and  ‘AvgMissionUsage’. 

•  Label  the  fields  Unit  ID,  Air,  Avg  Air  Usage,  Ground,  Avg  Ground 
Usage,  Total  Missions,  Avg  Mission  Usage. 

•  The  structure  should  look  like  Figure  56. 


119 


e  HI  afipanelSplitter  -  vertical 
8  CD  Panel  Splitter  facets 
effl  f:  facet  -  first 

&  []  af:panelBox  -  Parent  Unit 


8 


af:panelFormLayout 


B  if3  af:inputText  -  *{ 
8  fji]  af:inputText  - 
B  af:inputText  -  -{ 


9  ijp  afiinputText  -  -{ 

8  af:inputText  -  *{ 

8  |3  afiinputText  -  -{ 

8  af:inputText  -  #{ 

8  Q  Panel  Form  Layout  facets 
8  G  Panel  Box  facets 
i-EQ  f:  facet  -  second 


..FrUnitld...  label} 

.  .TotalAirMissions. .  .label} 

. .  AvgAirMissionUsage . . .  label} 


.TotalGroundMissions. .  .label} 

. .  AvgGroundMissionUsage. .  .label} 
.  .TotalMission. .  .label} 

. .  AvgMissionUsage . . ,  label} 


Figure  56.  Combo  Page  Structure 


7.  Under  the  second  facet  of  the  second  splitter,  add  a  ‘Panel  Splitter’. 

•  Orientation:  Horizontal. 

•  Splitter  Position:  500. 

8.  Under  the  second  facet  of  the  third  splitter,  add  a  ‘Panel  Box’  labeled 
‘Ground  missions’. 

•  Add  a  ‘Table’  by  dragging  the  ‘Combo_ParentUnit_GroundMissionV01’ 
from  the  Data  controls  tab. 

•  Select  ADF  table. 

•  Select  ‘Read-only  form’  and  ‘row_navigation’ . 

•  Delete  all  attributes  except  for  ‘Name’  ‘Missionld’  ‘ArrivalTime’  and 
‘MissionUsage’. 

•  Label  the  fields  Unit  Name,  Mission  ID,  Mission  Date,  and  Mission 
Usage. 

•  Add  an  additional  column  to  the  table  and  label  it  Usage  meter 

-  Drag  and  drop  a  ‘Gauge’  into  this  column 

-  The  properties  should  be  set  as  shown  in  Figure  57. 
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B  Common 

Rendered: 
o  Id: 

o  GaugeType: 
GaugeSetColumnCount: 
GaugeSetAlignment: 
GaugeSetDirection : 

9  Value: 


H  Gauge  Data 

9  Value: 

TabularData: 
o  Min  Value: 
o  MaxValue: 


Figure  57.  Gauge  Properties 

-  Under  the  ‘ThresholdSet’  tab,  add  three  thresholds. 

-  Threshold  1: 

-  Fill  color:  #ff0000 

-  ThresholdMaxValue:  60.0 

-  Threshold  2: 

-  Fill  color:  #ffff00 

-  ThresholdMaxValue:  80.0 

-  Threshold  3: 

-  Fill  color:  #00ff00 

-  ThresholdMaxValue:  100.0 

-  Under  the  metric  label,  change  number  type  to  ‘NT_Percent’. 
•  The  structure  should  look  like  Figure  58. 
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S  Q  afipanelSplitter 

B  Q  Panel  Splitter  facets 
©  B  f:  facet  -  first 
B  '  2  f:fecet  -  second 

aO  afipanelBox  -  Ground  Missions 
$  H  af:table  - 12 

|  |  af: column  Name. label} 

B  H  af: column  -  #{...MissionId. label} 

0  |  af: column  -  *{...ArrivalTime. label} 

B  H  af: column  -  *{...MissionUsagePercent. label} 
B  H  af: column  -  Usage  Meter 
B  03  Table  facets 
©  OH  Panel Box  facets 

Figure  58.  Combo  Page  Structure 


9.  The  final  structure  of  the  Combo  page  should  look  like  Figure  59. 

B  Q  af : document  -  Combo. jsf 

f . ^  af:  messages 

B  HD  afiform 

B  CO  af:panelSplitter  -  vertical 
B'  Q  Panel  Splitter  facets 
B  h  facet  -  first 

[□1  afiimage  -  #{...} 
a  a  fifacet  -  second 

a  □  afipanelSplitter  -  vertical 
B  OH  Panel  Splitter  facets 
©  a  h facet  -  first 
I  a  □  afipanelBox  -  Parent  Unit 
B  a  h  facet  -  second 
BQ  afipanelSplitter 

B  OH  Panel  Splitter  facets 
a  m  f:  facet  -  first 

a  □  afipanelBox  -  Air  Missions 
aa  f:  facet  -  second 

a  n  afipanelBox  -  Ground  Missions 

B  §a  af:panelGroupLayout 
B  C3  af: button  -  Air 
B  CJ  af-.button  -  Ground 
0-Q  af:button  -  Home 
a  Q  af:button  -  Totals 
B  O  Panel  Group  Layout  facets 

Figure  59.  Combo  Page  Structure 
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F. 


COMBO  TOTALS 


1.  Create  a  new  page  using  the  same  format  as  above. 

2.  Add  the  logo  as  above. 

3.  Under  the  page’s  original  vertical  panel  splitter,  at  a  ‘Panel  Group  Layout’ 
and  configure  the  buttons  as  above. 

•  Buttons  for  the  subpages  will  have  the  following  properties. 

-  Button  Inline  Style:  height:50px;  width:90px;  font-size:large;  text- 
align:center;  vertical-aligmbaseline;  line-height:40px;  font-weight:bold;  font- 
family:"  Arial  Black  color:#000052;  border-color:#000052;  border-width:thick; 

4.  Those  two  sections  should  be  formatted  as  shown  in  Figure  60. 

af:  document  -  ComboTotals.jsf 
□  af:  messages 
[iil  afiform 

9-m  af:panelSplitter  -  vertical 
Ei  Q  Panel  Splitter  facets 
effl  f:  facet  -  first 

;  [□]  af: image  -  #{...} 

B-  f:  facet  -  second 
B  §a  af:panelGroupLayout 
$  Q  af:button  -  Combo 
BO  af:button  -  Home 
B  Q  Panel  Group  Layout  facets 

Figure  60.  Combo  Total  Page  Structure 

5.  Under  the  second  facet  of  the  first  splitter,  add  a  ‘Panel  Splitter’. 

•  Orientation:  Vertical. 

•  Splitter  Position:  300. 

6.  Under  the  first  facet  of  the  second  splitter,  add  a  ‘Panel  Splitter. 

•  Orientation:  Horizontal. 

•  Splitter  Position:  700. 

7.  Under  the  first  fact  of  the  third  splitter  add  a  ‘Panel  Box’  labeled  ‘Unit’. 

•  Add  a  ‘Panel  Form  Layout’  by  dragging  the  ‘Combo_UnitIDV01’  from 
the  Data  controls  tab. 
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Select  ADF  Form. 


Select  ‘Read-only  form’  and  ‘row_navigation’ . 
Delete  all  attributes  except  for  ‘Name’. 

Label  the  field  Unit  Name. 

The  structure  should  look  like  Figure  61. 


S  □  af:panelSplitter 

B  Si  Panel  Splitter  facets 

effl  f:  facet  -  first 

b  Q  af:panelBox  -  Unit 

B  [si]  afipanelFormLayout 

B  af:inputText  -  #{. .  .Name. .  .label} 

B  Si  Panel  Form  Layout  facets 

B  CD  Panel  Box  facets 
i.  m  ,  , 

Figure  61.  Combo  Total  Page  Structure 


Under  the  second  fact  of  the  third  splitter,  add  ‘Panel  Box’  labeled  ‘Total 
Missions’. 

Add  a  ‘Bar  Graph’  by  dragging  ‘Combo_ParentUnitV02’  from  the  data 
control  tab. 

Under  the  ‘Series  Set’  pick  two  colors  to  represent  the  two  attributes  (Air 
and  ground  missions). 

Add  two  ‘Attribute  formats’  inside  the  bar  graph. 

-  Attribute  Format  1:  Total  Ground  Missions 

#  { bindings  .Combo_ParentUnitV  02  .hints  .T  otalGro 
undMissions. format} 

-  Attribute  Format  2:  Total  Air  Missions 

#{  bindings. Combo_ParentUnitV02. hints. TotalAir 
Missions. format } 

‘YITitle’  is  Number  is  missions. 

The  structure  should  look  like  Figure  62. 


B  ••[]]  afipanelSplitter 

B  Pi  Panel  Splitter  facets 
©  ffl  f:  facet  -  first 

f:  facet  -  second 

sQ  af:panelBox  -  Total  Missions 
©  Ul  dvt:barGraph 
B  dvt:background 

^  dvt:specialEffects 
i  ^  dvt:graphPlotArea 
B  dvt:seriesSet 
?  ^  dvtiseries 

1 . dvt:  series 

:  O  dvt:olAxis 
I dvt:ylAxis 
O  dvt:legendArea 
B  dvt:attributeFormat 

;  Mi  afxonvertNumber  -  number 
B  dvtiattributeFormat 

[Ml  afxonvertNumber  -  number 
I-  &  dvtiylTitle 

dvt:legendTitle 
©■■■^>  dvt:legendText 
&  Q  Bar  facets 
©  PH  Panel  Box  facets 

Figure  62.  Combo  Total  Page  Structure 

Under  the  second  facet  of  the  second  splitter,  add  a  ‘Panel  Splitter’ . 

Orientation:  Horizontal. 

Splitter  Position:  700. 

Under  the  first  facet  of  the  fourth  splitter,  add  a  ‘Panel  Box’  label  ‘Ground 

Mission  Usage’. 

Add  a  ‘Bar  Graph’  by  dragging 

‘Combo_ParentUnit_GroundMissiontV02’  from  the  data  control  tab. 

Under  the  ‘Series  Set’  pick  three  colors  to  represent  the  three  attributes 

(red,  yellow,  and  green  for  the  different  levels  of  usage). 

Add  three  ‘Attribute  formats’  inside  the  bar  graph. 

-  Attribute  Format  1:  Red  Ground  Mission  Usage 

#  { bindings  .Combo_ParentUnitV 022 .hints  .RedGro 
undMissonUsage. format. } 

-  Attribute  Format  2:  Yellow  Ground  Mission  Usage 

#  { bindings  .Combo_ParentUnitV022 .hints  .Yellow 
GroundMissionUsage. format} . 
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-  Attribute  Format  3:  Green  Ground  Mission  Usage 

#  { bindings  .Combo_ParentUnitV022 .hints .  GreenGr 
oundMissionUsage. format} . 

‘YITitle’  is  Number  is  Number  of  Missions. 

The  structure  should  look  like  Figure  63. 


BUI  afipanelSplitter 

B  Qd  Panel  Splitter  facets 
Bffl  f:  facet  -  first 

i  B  □  afipanelBox  -  Ground  Mission  Usage 
$•  Ul  dvt:barGraph 
i  O  dvt:  background 
} o  dvt:graphPlotArea 
B  dvt:seriesSet 

[ . ^  dvt:series 

[•••  ^  dvt:  series 

: . O  dvt:series 

O  dvtiolAxis 
3>dvt:ylAxis 
O  dvt:  legend  Area 
B  ^  dvt:attributeFormat 
L  (Ml  af:convertNumber 
B  dvt:attnbuteFormat 
GH  af:convertNumber 
B  ^  dvt:attributeFormat 
-  mil  af:convertNumber 
^  dvt:y  lTitle 
B  Q  Bar  facets 

Figure  63.  Combo  Total  Page  Structure 

Under  the  second  facet  of  the  fourth  splitter,  add  a  ‘Panel  Box’  label  ‘Air 
Mission  Usage’. 

Add  a  ‘Bar  Graph’  by  dragging  ‘Combo_ParentUnit_AirMissiontV02’ 
from  the  data  control  tab. 

Under  the  ‘Series  Set’  pick  three  colors  to  represent  the  three  attributes 
(red,  yellow,  and  green  for  the  different  levels  of  usage). 

Add  three  ‘Attribute  formats’  inside  the  bar  graph. 

-  Attribute  Format  1:  Red  Air  Mission  Usage 

#  { bindings  .Combo_ParentUnitV 022 .hints  .RedAir 
MissonUsage  .format } 

-  Attribute  Format  2:  Yellow  Air  Mission  Usage 


#{  bindings. Combo_ParentUnitV022.hints.  Yellow 
AirMissionUsage. format } 

-  Attribute  Format  3:  Green  Air  Mission  Usage 

#  { bindings  .Combo_ParentUnitV022 .hints .  GreenAi 
rMis  sionU  sage,  format } 

‘YITitle’  is  Number  is  Number  of  Missions. 

The  structure  should  look  like  Figure  64. 

B  □  af:panelSplitter 

&  Q  Panel  Splitter  facets 
9  f:  facet  -  first 
effl  f:  facet  -  second 

bQ  af:panelBox  -  Air  Mission  Usage 
9  Ul  dvt:barGraph 

B  dvt:  background 

i  ^  dvt:graphPlotArea 
B  dvtiseriesSet 

\  &  dvt:olAxis 
dvt:y  lAxis 

9"0  dvt:attributeFormat 
;  M  afxonvertNumber 
9-0  dvt:attributeFormat 

1 . [Ml  afxonvertNumber 

9"^>  dvt:attributeFormat 
1  QH1  afxonvertNumber 
[•■■■  dvt:y  ITitle 

B  Q  Bar  facets 
B  Q  Panel  Box  facets 


Figure  64.  Combo  Total  Page  Structure 
The  final  structure  of  the  Combo  page  should  look  like  Figure  65. 


B  [_j  afidocument  -  ComboTotals.jsf 
□  af:  messages 
B  [iij  afiform 

B-IT1  af:panelSplitter  -  vertical 
B  £Q  Panel  Splitter  facets 
effl  f:  facet  -  first 

[□]  afiimage  -  #{...} 
f:  facet  -  second 

B  □  af:panelSplitter  -  vertical 
B  Q  Panel  Splitter  facets 
Bffl  fifacet  -  first 

B  Q  afipanelSplitter 

B  Pl  Panel  Splitter  facets 
B  03  f:facet  -  first 
B-Q  af:panelBox 
f:  facet  -  second 
B  □  afipanelBox 
Bffl  f:  facet  -  second 
B  [x]  af:panelSplitter 

B  'Q  Panel  Splitter  facets 
Bffl  f:  facet  -first 
I  ®  □  afipanelBox 
B  03  fifacet  -  second 
B  □  afipanelBox 

B  ^  afipanelGroupLayout 
B-O  afibutton  -  Combo 
i  Q  afibutton  -  Home 
B  Q  Panel  Group  Layout  facets 

Figure  65.  Combo  Total  Page  Structure 

G.  DEPLOYING  TO  WEBLOGIC  SERVER  FOR  TESTING 

1.  Once  all  pages  are  built  and  the  Task  flow  is  updated  with  links,  run  the 
application  for  testing. 

2.  Select  Run. 

3.  Select  ‘Run  ViewController.jpr’ . 

4.  JDeveloper  will  connect  to  the  Weblogic  Server  and  run  the  application  in 
a  web  browser. 

5.  This  can  be  used  to  test  the  pages’  functionality  and  ensure  all  buttons  are 
linked  properly. 


-Unit 

-Total  Missions 

-  Ground  Mission  Usage 

-  Air  Mission  Usage 
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